آژانس‌ها
یک قیف، بیست مشتری، بیست اعتبار که جدا نگه داشته می‌شوند
یک آژانس سه‌نفره که بازاریابی بیست کسب‌وکار محلی را انجام می‌دهد، بیست بار یک مشکل و بیست بار یک راه‌حل دارد — با این استثنا که فهرست مخاطبان، هویت ارسال، دامنه و سابقه رضایت هر مشتری باید کاملاً متعلق به خودش بماند. کار جالب در همان «استثنا» است.
یک پروژه به ازای هر مشتری، و مرزکشی کارِ پایگاه داده است
همه‌چیز در اینجا به یک مستأجر و یک پروژه با هم محدود می‌شود — مخاطبان، قیف‌ها، محتواهای خلاقانه، کمپین‌ها، هویت‌های ارسال، گزارش‌ها. این محدودسازی با امنیت سطح ردیف در پایگاه داده اعمال می‌شود، نه با یک شرطی که کسی باید یادش بماند به پرس‌وجو اضافه کند. پروژه‌ای که فراموش شده باشد، چیزی نمی‌بیند، نه ردیف‌های پروژه اول را.
یعنی فهرست یک مشتری نمی‌تواند به اشتباه به کمپین مشتری دیگری نشت کند، و یعنی یک گزارش درباره یک مشتری است، چون ساختاراً نمی‌تواند درباره دو مشتری باشد.
هر مشتری با هویت خودش ارسال می‌کند
یک هویت ارسال متعلق به یک پروژه است: دامنه خودشان، کلیدهای DKIM خودشان، صندوق پستی یا حساب ارائه‌دهنده خودشان، سقف نرخ ارسال خودشان. کمپین ناموفق یک مشتری نمی‌تواند تحویل‌پذیری مشتری دیگری را خراب کند، چون هرگز چیزی مشترک نداشته‌اند که خراب شود.
این کار یک گفت‌وگوی ناخوشایند را هم زودتر حل می‌کند. مشتری مالک ارسالش، فهرستش و سابقه رضایتش است. وقتی می‌رود — و بعضی‌ها خواهند رفت — همه‌اش را با خود می‌برد، و شما گروگان‌گیری‌ای نساخته‌اید که مجبور باشید توضیحش دهید.
- 1مخاطبانبه ازای هر پروژه. در پایگاه داده اعمال می‌شود، نه با پرس‌وجویی که باید یادتان بماند.
- 2ارسالدامنه خودشان، DKIM خودشان، صندوق پستی یا ارائه‌دهنده خودشان، سقف نرخ خودشان.
- 3رضایتدفتر ثبت خودشان. اگر بروند، با خودشان می‌برد، مدارک و شواهد هم همراهش.
- 4گزارش‌هابه ازای هر پروژه، از اساس. راهی برای تجمیع تصادفی دو مشتری وجود ندارد.
- اطلاعاتآنچه نزد خودتان می‌ماندتعریف قیف‌ها و شیوه کارتان. آن محصول شماست و همان بخشی است که ارزش استفاده مجدد دارد.
بدون اعتبار مشترکبدون فهرست مشترک
استفاده مجدد بدون کپی‌پیست
قیف را یک بار بسازید. به تعداد مشتری‌هایتان مستقرش کنید.
قیف یک گراف است، و گراف یک سند JSON با شماره منتشرشده است. یعنی چیزی که دوباره استفاده می‌کنید یک سند است، نه اسکرین‌شاتی از صفحه‌ای که باید در هر حساب با دست از نو بسازید.
قیف‌های استاندارد خودتان
خوش‌آمدگویی، سبد رهاشده، عدم حضور، فاصله‌ای، بازگشت مشتری. یک بار نوشته‌شده توسط کسی که در آن بهترین است، نگه‌داری‌شده در مخزن خودتان، و ساخته‌شده در پروژه مشتری با یک فراخوانی API.
همه‌جا به یک شکل بررسی‌شده
اعتبارسنج روی قیف شما در هر پروژه‌ای که فرود می‌آید اجرا می‌شود. گرافی که بدون یک انتظار حلقه می‌زند یا بدون موضوع ارسال می‌کند، آنجا هم رد می‌شود، همان‌طور که اینجا رد می‌شود.
شبیه‌سازی‌شده پیش از اجرا
یک مخاطب واقعی از فهرست همان مشتری را در حالت آزمایشی از قیف عبور دهید و ببینید چه چیزی برایش ارسال می‌شد. این کار را یک بار در هر استقرار انجام دهید و گفت‌وگوی «اشتباه ارسال شد» دیگر رخ نمی‌دهد.
بهبودیافته در یک جا
وقتی چیزی یاد می‌گیرید — مثلاً یادآور دوم در ساعت ده صبح بهتر جواب می‌دهد — تعریفتان را تغییر می‌دهید و آن را جلو می‌برید. مشتری‌هایی که نسخه قدیمی را اجرا می‌کنند روی همان نسخه قدیمی تمام می‌کنند؛ هیچ‌کس در میانه کار آشفته نمی‌شود.
محتواهای خلاقانه هم
یک محتوای خلاقانه سندی است با متغیرهای ادغام. همان ایمیل خوش‌آمد، رندرشده با برند، رنگ‌ها و لوگوی هر مشتری — که در اولین اجرا از وب‌سایت خودشان برداشته می‌شود.
یا بگذارید یک عامل انجامش دهد
یک دستیار را به سرور MCP اشاره دهید، محدود به یک پروژه، و از آن بخواهید قیف را برای آن مشتری پیش‌نویس و بررسی کند. هر چیزی که به یک انسان واقعی می‌رسد همچنان به تأیید صریح نیاز دارد و داخل سهمیه می‌ماند.
یازده مشتری، یازده فرستنده، یک جا برای نگاه کردن.
مشکل گزارش ماهانه
بیشتر درد گزارش‌دهی آژانس، تولید اعداد نیست. تولید اعدادی است که از پرسیدن یک سؤال بعدی توسط مشتری جان سالم به در می‌برند، و تولیدشان بدون سه ساعت اسکرین‌شات گرفتن در اول ماه.
دو چیز اینجا کمک می‌کند. گزارش‌ها مسیرهای API هستند، پس بسته ماهانه را می‌توان با یک اسکریپت سرهم کرد و به‌صورت PDF صادر کرد، نه با یک آدم و یک صفحه‌گسترده. و اعداد درباره ربات‌ها صادق‌اند: خام و فیلترشده هر دو در دسترس‌اند، با برچسب، پس وقتی مشتری می‌پرسد چرا نرخ باز شدن بعد از جابه‌جایی‌اش افت کرد، می‌توانید در یک جمله توضیحش دهید، نه اینکه در چهار جمله از آن دفاع کنید.
همان کاشی‌ها در dash-b قرار می‌گیرند — عملکرد کمپین، ریزش قیف، رشد فهرست، تحویل‌پذیری بر اساس دامنه — پس مشتری‌ای که یک داشبورد زنده می‌خواهد می‌تواند داشته باشد، روی حساب خودش، با اعتبارنامه‌های خودش و بدون هیچ کلیدی از شما در صفحه.
- 1برای هر پروژهیک توکن، یک محدوده پروژه، همان اسکریپت.
- 2دریافتعملکرد کمپین، ریزش قیف، رشد فهرست، تحویل‌پذیری بر اساس دامنه.
- 3رندرسند خلاقانه آن‌ها به‌عنوان یک صفحه گزارش، و سپس به PDF.
- 4ارسالیا در بردشان قرارش دهید. هر کدام که مشتری واقعاً می‌خواند.
- اطلاعاتچه چیزهایی تغییر کردهسه ساعت اسکرین‌شات به یک کار زمان‌بندی‌شده تبدیل شد، چون گزارش‌ها از ابتدا مسیر (route) بودند.
خام و فیلترشده، هر دو برچسب‌گذاری‌شده
گفت‌وگو درباره رضایت، در همان ابتدا
هر آژانسی با آن مشتری روبه‌رو شده که با یک صفحه‌گسترده چهار هزار آدرسی و پاسخی مبهم درباره منشأ آن‌ها می‌آید. اینجا این چیزی نیست که مجبور باشید درباره‌اش بحث را ببرید؛ یک فیلد است.
واردات در بهترین حالت به‌عنوان «منافع مشروع» ثبت می‌شود، هرگز به‌عنوان «رضایت»، و ترکیب مبناهای قانونی پیش از ارسال هر کمپینی نمایش داده می‌شود. اگر فهرستی قابل ارسال نباشد، این را در لحظه واردات می‌گوید، نه در لحظه شکایت. این یک قضاوت دشوار را به خواندن مشترکِ یک صفحه تبدیل می‌کند — که وقتی مشتری اصرار می‌ورزد، موقعیت بسیار بهتری برای شماست.
شایسته است که با صدای بلند به مشتری بگویید: اعتباری که با یک فهرست بد در خطر قرار می‌گیرد اعتبار خودِ اوست، روی دامنه خودش، چون هر پروژه به نام خودش ارسال می‌کند. این استدلال قوی‌تر از هر مقرراتی است و همان است که معمولاً اثر می‌گذارد.