فرق SaaS والمنتجات
منتجك يعرف أشياء لا يمكن لأي أداة تسويقية ملاحظتها
من أنهى الإعداد الأولي ومن توقف عند الخطوة الثالثة. من دعا زميلاً. من وصل إلى الحد مرتين هذا الأسبوع. من لم يفتح الشيء منذ أسبوعين. كل واحد من هذه مشغّل أفضل من أي شيء مستنبط من فتح بريد إلكتروني، وكلها على بُعد سطرين من الشيفرة.
الأحداث هي التكامل بأكمله
POST /v1/events ببرنامجك المميز الخاص: اسم اخترته، وجهة اتصال، حمولة، ومفتاح عدم التكرار. هذا هو الاتصال بأكمله. لا توجد حزمة تطوير تتطلب التحديث، ولا شاشة ربط، ولا مفردات من عندنا عليك ترجمة منتجك إليها.
يصل كل حدث إلى سجل جهة الاتصال غير القابل للإلحاق، ومن هناك يكون ثلاثة أشياء في آنٍ واحد. مشغّلاً، فيبدأ القمع عند وصوله. مسنداً، فيمكن لشريحة أن تقول "فعل هذا خلال الأربعة عشر يوماً الماضية" أو، الأكثر فائدةً، "لم يفعله". وهدفاً، فتنتهي السلسلة في اللحظة التي يفعل فيها شخص ما الشيء الذي كان يُشجَّع عليه.
الشيء الثالث هو ما يجعل رسائل دورة الحياة محتملة الاستقبال. التذكير بإكمال إعداد حسابك يجب أن يتوقف عن الوجود في اللحظة التي يُع فيها الحساب، وفي معظم الأدوات لا يحدث ذلك، لأن السلسلة والمنتج لا يتحدثان مع بعضهما.
- ⚡مشغّل
api_event—signup.completed، الخطةfree. - 2إرسال بريد إلكترونيالشيء الوحيد الذي يجب فعله أولاً. وليس جولة في أحد عشر ميزة.
- 3انتظار يومين
wake_atعلى العملية. لا شيء في قائمة الانتظار، ولا شيء يجب تفكيكه إذا أعدت كتابة هذا غداً. - ?شرطهل وصل
project.created؟ لا → الفرع المساعد. نعم → الهدف أدناه. - 4الفرع المساعدرسالة واحدة، تعرض الشيء المحدد الذي لم يفعله. ثم انتظار ثانٍ.
- 5الهدفيصل
project.created. تنتهي العملية. لا بريد إعداد أولي إضافي، أبداً، لهذا الشخص.
أسماء أحداثكتعريفك للتفعيل
خمس قِمَم تحويل
دورة الحياة، بالترتيب الذي تحدث به فعلاً
1 · التفعيل
المُحفِّز: التسجيل. رسالتان أو ثلاث، كل واحدة عن إجراء واحد، ولكل منها هدف يُنهي التسلسل عند حدوث ذلك الإجراء. هذه أقوى قمع تحويل ستبنيها، والأكثر استحقاقًا لإعادة الكتابة ثلاث مرات.
2 · التوقف
المُحفِّز: segment_enter — سجّل لكن بلا حدث ذي معنى منذ سبعة أيام. رسالة واحدة تسأل بدل أن تُلقي، وأخرى تعرض شيئًا محددًا. ثم توقّف. رسالة رابعة لشخص تجاهل ثلاثًا هي رسالة إلى لا أحد.
3 · لحظة التوسع
المُحفِّز: حدث يدل على أنه يحصل على قيمة — بلغ الحد الأقصى، دعوة زميل ثالث، تصدير للمرة الثانية. هذه هي اللحظة الوحيدة التي تُرحَّب فيها برسالة ترقية، وهي لحظة يستطيع منتجك تسميتها بدقة.
4 · التجديد وتحصيل المدفوعات
المُحفِّز: date_field قبل التجديد، أو حدث دفع. إشعار، وتذكير، و— إذا فشلت عملية دفع — تسلسل قصير يتوقف فور نجاحها. عُقد الأهداف ليست اختيارية في تحصيل المدفوعات؛ فهي الفرق بين تذكير ومضايقة.
5 · استعادة العملاء
المُحفِّز: segment_enter — ألغى الاشتراك أو خامل منذ ستين يومًا. رسالتان صادقتان، ثم وسم وصمت. ما تغيّر منذ رحيله رسالة أفضل من خصم.
والداخلي منها
notify_team يُبلغ إنسانًا عندما يعبر حساب يستحق اهتمام بَشري حدًّا ما. ليس من الضروري أن ينتهي القمع برسالة بريد إلكتروني إلى عميل؛ أحيانًا الإجراء الصحيح هو إخبار أحد زملائك أن يلتقط الهاتف.
لا أحد يتخلى عن الخدمة عمدًا. إنه فقط يتوقف عن فتحها.
لماذا قد يعجب هذا المطوّر فعلًا
الأجزاء المهمة عندما تكون أنت من يُجري التكامل
لا نقاط نهاية خاصة
كل شاشة قابلة للبناء من واجهة البرمجة العامة، لأنه لا يوجد نوع آخر. إذا أردت تضمين تقرير حملة في لوحة تحكّمك الخاصة، فلا شيء يعترض طريقك ولا شيء يحتاج إلى هندسة عكسية.
مفاتيح تكرارية في كل مكان
في كل مسار يُغيِّر البيانات. منطق إعادة المحاولة لديك، وطابور التسليم مرة على الأقل، وشبكتك المتقطعة — كلها تصبح مشكلة شخص آخر، وتحديدًا مشكلة فهرس فريد.
حاكِ قبل الإطلاق
POST /v1/simulate يُجري تشغيلًا تجريبيًا لجهة اتصال عبر قمع تحويل ويعيد المسار وكل رسالة كان سيرسلها. ضعه في التكامل المستمر إن شئت: القمع رسم بياني، والرسم البياني قابل للاختبار.
خادم MCP
وجِّه وكيلًا ذكيًا إلى /mcp ودعه يؤلف القِمَم ويتحقق منها. الأدوات القادرة على الإرسال تتطلب تأكيدًا صريحًا ويحدّها حصة، فلا يمكن أن يتحول سوء فهم للتوجيه إلى خمسين ألف رسالة بريد إلكتروني.
خطاطات الويب الصادرة
موقَّعة، تُعاد المحاولة بتدرّج، مرة واحدة على الأقل. وبنفس مفردات الأحداث التي تستخدمها التقارير، حتى لا يختلف مستودعك ولوحة تحكّمك حول معنى «تم التسليم».
محوٌ يصل فعلًا
طلب الحذف يزيل جهة الاتصال وسجل رسائلها هنا، وينتشر إلى كل خدمة شقيقة تحتفظ بنسخة. طلب واحد، نتيجة واحدة، وشيء تستطيع الإشارة إليه عند السؤال.
أين يقع الحد الفاصل
يحتفظ ClickSomo بقائمة بريدية وبما فعلته تلك القائمة. إنه ليس قاعدة بيانات مستخدميك ولا يسعى إلى أن يكون كذلك: جهة الاتصال لا تحمل أبدًا بيانات اعتماد، ولا تسجّل الدخول أبدًا، ولا تتحول أبدًا إلى حساب. مستخدموك يعيشون في منتجك؛ وجهات الاتصال تعيش هنا، ويجمع بينهما عنوان البريد الإلكتروني والأحداث التي تختار إرسالها.
هذا الفصل مقصود، وهو سبب نجاح نموذج الموافقة. أنت المسؤول عن معالجة البيانات لمستخدميك؛ ونحن نعالج نيابة عنك. التصميم الذي تتحول فيه أداة تسويق بصمت إلى مخزن هويات هو تصميم لا يمكن فكّه لاحقًا، وهو بالضبط الفشل الذي بُني هذا التصميم لتفاديه.
النسخة العملية: أرسل الأحداث، وأرسل الخصائص التي تريد التقسيم بناءً عليها، واترك كل شيء آخر في مكانه. إذا وجدت نفسك تدفع مخططك بالكامل إلى هنا، فالتقسيم الذي تحاول بناءه هو على الأرجح استعلام في قاعدة بياناتك يجب أن يصلك كخاصية منطقية واحدة بدلًا من ذلك.