مخاطبان و رضایت
فهرستی که می‌توانید از آن دفاع کنید، نه صرفاً فهرستی که دارید
هر کسی می‌تواند ده هزار نشانی ایمیل داشته باشد. پرسش مهم — همان که نهاد ناظر، ارائه‌دهنده و وجدان خودتان هر یک با واژه‌هایی کمی متفاوت می‌پرسند — این است که هر نشانی از کجا آمده و بر چه اساسی حق نوشتن به آن را دارید. ClickSomo این را به یک واقعیت ذخیره‌شده تبدیل می‌کند، نه چیزی که مجبور باشید بازسازی‌اش کنید.
هویت همان نشانی ایمیل است
یک مخاطب برای هر نشانی در هر پروژه، که توسط پایگاه‌داده تضمین می‌شود، نه با امید و آرزو. نشانی‌ها هنگام نوشتن نرمال‌سازی می‌شوند، نه هنگام خواندن — اگر هنگام خواندن نرمال‌سازی کنید، این محدودیت فقط تزئینی است و اجازه می‌دهد هم Anna@ و هم anna@ وارد شوند.
شماره‌های تلفن در صورت وجود به صورت E.164 ذخیره می‌شوند، اما شماره تلفن یک ویژگی است، نه یک هویت. هیچ گراف حل هویت، هیچ پروتکل ادغام و هیچ سابقه ممیزی ادغام‌ها وجود ندارد، زیرا هر مخاطب در اینجا از طریق کانالی می‌رسد که از قبل نشانی دارد: یک واردکردن، یک فرم، یک اشتراک، یا کد خود شما.
نام به صورت کامل ذخیره می‌شود
display_name دقیقاً همان‌طور که داده شده نگه داشته می‌شود و هرگز به بخش‌هایی تقسیم نمی‌شود. تقسیم نام کارخانه باگ است — «van der Berg»، «Kim Min-jun»، نام‌های تک‌بخشی، القاب، و هر قرارداد ترتیبی که انگلوساکسون نیست — و یک تقسیم اشتباه در برچسب ادغام به شکل «Dear van،» ظاهر می‌شود که از بی‌شخصی‌سازی کامل هم بدتر است.
بخش‌های ساختاریافته فقط برای منابعی وجود دارند که آن‌ها را از قبل جدا شده ارائه می‌دهند. هیچ‌چیز آن‌ها را استخراج نمی‌کند. و نامی که خود شخص تایپ کرده هرگز توسط یک فایل CSV بعدی که اتفاقاً چیز متفاوتی ثبت کرده بازنویسی نمی‌شود، زیرا قاعده «آخرین نوشنده برنده است» اجازه می‌دهد بی‌دقت‌ترین واردکردن پیروز شود.
- 1هویترایانامه، نرمال‌سازی‌شده. منحصربه‌فرد درون پروژه.
- 2نامبه صورت کامل ذخیره می‌شود.
first_nameدر زمان رندر استخراج می‌شود، هرگز ذخیره نمی‌شود. - 3ویژگی‌هاهر چه بخواهید، به صورت JSON. متعلق به شما، و قابل درون‌ریزی به صورت
attrs.*. - 4برچسب‌ها و فهرست‌هابرچسب‌ها درجه یک هستند و در یک انبار زندگی می‌کنند؛ فهرست‌ها عضویت صریح هستند.
- 5رضایتیک ردیف برای هر کانال، همراه با مبنای قانونی و مدرک آن.
- 6رویدادهایک گزارش فقط‌الحاقی از هر کاری که این شخص انجام داده. جدولی که کل محصول بر آن استوار است.
- ×هرگزبدون رمز عبور، بدون هش، بدون نشست، بدون کلید API. ستونی که کسی را احراز هویت کند یک حادثه است، نه یک ویژگی.
محدود به مستأجر و پروژه، هر دو
دفتر رضایت
نبودن، اجازه نیست
یک ردیف برای هر مخاطب در هر کانال — رایانامه، پیامک، نامه، پوش — که هر کدام دارای یک وضعیت، یک مبنای قانونی، یک منبع، مدرک، مهرهای زمانی و حوزه قضایی است. مخاطبی که برای کانالی ردیف مبنایی ندارد، نمی‌تواند چیزی در آن کانال دریافت کند. نه «علامت‌گذاری شده است». نمی‌تواند.
consent
کسی فعالانه درخواست کرده است. یک ارسال فرم با مدرک ذخیره‌شده، یک تأیید دوعاملی، یا چک‌باکسی که خودشان تیک زده‌اند. این قوی‌ترین مبناست و تنها مبنایی است که یک فرم می‌تواند تولید کند.
legitimate_interest
بهترین چیزی که یک واردکردن CSV می‌تواند به آن برسد. یک صفحه‌گسترده نمی‌تواند به یاد داشته باشد که کسی با چیزی موافقت کرده، پس هرگز اجازه ندارد چنین ادعایی کند — و بارگذاری مجدد همان فایل آن را ارتقا نمی‌دهد.
contract
شما به دلیل چیزی که هر دو طرف آن هستید به آن‌ها می‌نویسید. یادآور خدمت، اطلاعیه تمدید، چیزی که اگر دریافت نکنند ناراحت می‌شوند.
پیش از ارسال یک کمپین، شما ترکیب مبنای مخاطبان آن را می‌بینید: چند نفر از این افراد درخواست کرده‌اند، چند نفر تحت منافع مشروع به آن‌ها می‌رسید، و چند نفر به دلیل قرارداد آنجا هستند. این یک عدد است که بیش از هر هشداری که تاکنون نوشته شده، جلوی ارسال‌های بد را گرفته است.
چرا این برای شما سخت‌گیرانه‌تر از حد لازم است: واقعاً به خاطر شما نیست. اعتبار ارسال انبوه یک منبع مشترک است و یک فهرست بی‌احتیاط، چاه را برای همه کسانی که از همان زیرساخت ارسال می‌کنند مسموم می‌کند. نرخ شکایت و برگشت هر مستأجر زیر نظر است و حسابی که نرخ‌هایش از آستانه بگذرد همین‌جا محدود می‌شود — پیش از آنکه ارائه‌دهنده این کار را با همه یکجا بکند.
پشت هر ردیف در این فهرست، کسی «بله» گفته است.
چهار راه ورود
هر مسیر ورود به فهرست شما، خودِ شما هستید که روی داده‌های خودتان عمل می‌کنید
هیچ مسیر ورود با توکن سرویس وجود ندارد و هیچ محصول هم‌خانواده‌ای بی‌سروصدا در مخاطبان شما نمی‌نویسد. اگر می‌خواهید کسی در فهرستی باشد، یکی از این چهار مورد او را آنجا گذاشته است.
واردکردن CSV
ستون‌به‌ستون نگاشت‌شده، نرمال‌سازی‌شده هنگام نوشتن، با بررسی MX تا دامنه‌های مرده و غلط‌تایپ‌شده پیش از برگشت سختگیرانه شناسایی شوند، و با مبنایی که صریحاً تعیین می‌کنید ثبت شوند. واردکردن یک شناسه می‌گیرد و هر مخاطبی که ایجاد کرده به آن اشاره می‌کند.
یک فرم ClickSomo
از همان سند بقیه چیزها رندر می‌شود، با اعتبارسنجی، تله هانی‌پات و محدودیت نرخ. یک ارسال، تنها مسیری است که می‌تواند به‌طور مشروع consent تولید کند، زیرا تنها مسیری است که شخص حاضر است.
صفحه‌ای که خودتان در dash-b ساخته‌اید
طراح داشبورد صفحات را منتشر می‌کند؛ فرمی روی یکی از آن‌ها با اعتبارنامه خودتان اینجا ارسال می‌شود. همان اعتبارسنجی، همان مدیریت رضایت، بدون یکپارچه‌سازی دومی برای نگهداری.
API عمومی
POST /v1/contacts با توکن خودتان، معناشناسی upsert، و پذیرش کلید idempotency. برنامه شما از قبل می‌داند چه کسی ثبت‌نام کرده؛ این کوتاه‌ترین مسیر از آن واقعیت تا یک قیف است.
سگمنت‌ها یک محمول (predicate) هستند، کامپایل‌شده
یک سگمنت درختی ذخیره‌شده از محمول‌ها روی فیلدهای مخاطب، ویژگی‌ها، برچسب‌ها، عضویت در فهرست و رفتار است که به SQL کامپایل می‌شود و همراه با یک شمارش ذخیره می‌شود. عملگرها همان عملگرهای معمولی‌اند — برابر است، برابر نیست، در، در نیست، شروع می‌شود با، پایان می‌یابد با، شامل است، مقدار دارد، مقدار ندارد — که با و، یا و نه تا هر عمقی که لازم دارید ترکیب می‌شوند.
پیش از استفاده، آن را پیش‌نمایش کنید. این نقطهٔ پایانی مخاطبان واقعی را برمی‌گرداند، پس «چه کسانی واقعاً در این هستند» پرسشی است که با نگاه کردن پاسخ می‌دهید، نه با ارسال کردن و فهمیدن.
سگمنت‌ها سپس دو نقش ایفا می‌کنند: به‌عنوان مخاطب یک کمپین، به‌عنوان شرط یک شاخهٔ قیف، و به‌عنوان محرکی مستقل — segment_enter در همان لحظه‌ای که کسی واجد شرایط می‌شود، یک اجرا را آغاز می‌کند.
- 1برچسب
tags contains "regular" - 2ویژگی
attrs.total_orders >= 3— فیلد شما، نام شما برای آن. - 3رفتاربدون رویداد
order.paidدر ۹۰ روز گذشته. - 4رضایتیک مبنای قابل استفادهٔ ایمیلی. مخاطبانِ بدون چنین مبنایی در شمارش نیستند، چون به هر حال نمی‌توان به آن‌ها چیزی فرستاد.
- اطلاعاتپیش‌نمایش۴۱۲ مخاطب، فهرست‌شده. هنگام ارسال دوباره شمرده می‌شود، چون یک سگمنت یک پرسش است، نه یک عکس فوری.
کامپایل‌شده به SQLشمارش ذخیره‌شده، پاسخ زنده
استثناها و زمان بررسی آن‌ها
استثناها در سطح پروژه و سراسری‌اند: برگشت‌های سخت، شکایات، لغو اشتراک‌ها، ثبت‌های دستی و نشانی‌های نقش‌محور. آن‌ها در زمان ارسال بررسی می‌شوند و سپس بار دیگر در خودِ سرویس ارسال.
همان بررسی دوم است که کار را انجام می‌دهد. قیفی که یک انتظار سه‌روزه در آن هست، پنجره‌ای سه‌روزه دارد که در آن کسی می‌تواند اشتراکش را لغو کند، و سیستمی که استثناها را هنگام صف‌شدن پیام بررسی کرده باشد، باز هم به او ایمیل می‌فرستد. بررسی در زمان ارسال، تفاوت میان احترام به یک لغو اشتراک و صرفاً ثبت آن است.
حذف داده هم به همین شکل کار می‌کند: یک درخواست حذف، مخاطب و تاریخچهٔ پیام‌های او را از اینجا برمی‌دارد و از طریق همان مسیر داخلی که بقیهٔ خانواده استفاده می‌کنند، به هر سرویس خواهری که نسخه‌ای از آن را نگه داشته می‌رسد. یک جا برای درخواست هست و یک اتفاق که می‌افتد.