شركات الـ SaaS وفرق المنتجات
منتجك عارف حاجات مفيش أداة تسويق تقدر تشوفها
مين خلّص الـ onboarding ومين وقف عند الخطوة التالتة. مين عيّل زميل. مين ضرب الحد مرتين الأسبوع ده. مين عمره ما فتح الحاجة من أسبوعين. كل واحدة من دول تريجر أحسن من أي حاجة متطلعة من فتح إيميل، وكلهم على بعد سطرين كود من إنهم يبقوا كده.
الإيفينتس هي التكامل كله
POST /v1/events بتوكنك الخاص: اسم اخترته، جهة اتصال، بيانات، ومفتاح idempotency. ده كله الاتصال. مفيش SDK لازم تفضل متحدث، ولا شاشة mapping، ولا مصطلحات من عندنا لازم تترجم منتجك ليها.
كل إيفينت بيتسجل في سجل جهة الاتصال اللي بيضاف عليه بس، ومن هناك هو تلات حاجات مرة واحدة. تريجر، يعني فانل بيبدأ أول ما يوصل. شرط، يعني الـ segment تقدر تقول "عمل الحاجة دي في آخر أربعتاشر يوم" أو — وأدق — "معملهاش". وجول، يعني السلسلة بتخلص في نفس اللحظة اللي الشخص يعمل فيها الحاجة اللي كانت بتنده عليه ليها.
التالتة دي هي اللي بتخلي رسايل دورة الحياة تبقى مقبولة إنك تستلمها. التنبيه اللي بيقولك كمّل إعداد حسابك المفروض يختفي تاني ما الحساب يخلص إعداد، وأغلب الأدوات ده مش بيحصل عندها، لأن السلسلة والمنتج مش بيتكلموا مع بعض.
- ⚡مشغل
api_event—signup.completed، خطةfree. - 2ابعت إيميلالحاجة الوحيدة اللي تعملها الأول. مش جولة في حداشر ميزة.
- 3استنى يومين
wake_atعلى الرن. مفيش حاجة في الطابور، ومفيش حاجة تتفك لو غيّرت ده بكرة. - ?شرط
project.createdوصل؟ لأ ← فرع المساعدة. أيوه ← الجول اللي تحت. - 4فرع المساعدةرسالة واحدة، بتعرض الحاجة المحددة اللي معملهاش. وبعدين انتظار تاني.
- 5الهدفلما بيوصل
project.created، التشغيلة بتخرج. مفيش إيميلات onboarding تاني خالص للشخص ده.
أسماء الأحداث بتاعتكتعريفك للتفعيل
خمس قمعات
دورة الحياة، بالترتيب اللي بيحصل بيه فعلاً
1 · التفعيل
المُطلِق: التسجيل. رسالتين أو تلاتة، كل واحدة عن إجراء واحد، وكل واحدة ليها هدف بيوقف السلسلة لما الإجراء ده يحصل. أقوى قمع هتبنيه، واللي يستاهل تعيد كتابته تلات مرات.
2 · الوقفة
المُطلِق: segment_enter — سجّل ومفيش حدث مفيد من سبع أيام. رسالة واحدة بتسأل مش بتأمر، وواحدة بتعرض حاجة محددة. وبعدين تقف. رسالة رابعة لحد تجاهل تلاتة رسالة لحد مش موجود.
3 · لحظة التوسّع
المُطلِق: حدث معناه إنهم بياخدوا قيمة — وصلوا للحد الأقصى، دعّوا زميل تالت، صدّروا للمرة التانية. دي اللحظة الوحيدة اللي رسالة الترقية فيها مقبولة، وهي لحظة منتجك يقدر يسمّيها بدقة.
4 · التجديد والتحصيل
المُطلِق: date_field قبل التجديد، أو حدث دفع. تنبيه، وتذكير، و— لو الدفع فشل — سلسلة قصيرة بتقف في اللحظة اللي بتنجح فيها. عقد الهدف مش اختياري في التحصيل؛ هو الفرق بين تذكير ومضايقة.
5 · استرجاع العملاء
المُطلِق: segment_enter — لغى الاشتراك أو ساكت من ستين يوم. رسالتين، صادقين، وبعدين تاج وسكوت. «إيه اللي اتغير من ساعة ما سابوا» رسالة أحسن من خصم.
والوحدة الداخلية
notify_team بيقول لحاجة بشرية لما حساب يستاهل حد بشري يعدي حد. القمع مش لازم ينتهي بإيميل لعميل؛ ساعات الإجراء الصح إن حد من عندكم ي pickup التليفون.
محدش بيسيب الخدمة عمدًا. هو بس بيوقف عن فتحها.
ليه المطور ممكن فعلاً يحب ده
الأجزاء اللي تهم لما تكون إنت اللي بتعمل التكامل
مفيش endpoints خاصة
كل شاشة قابلة للبناء من الـ API العام، لأن مفيش نوع تاني. لو عايز تحط تقرير حملة في لوحة التحكم بتاعتك، مفيش حاجة واقفة في طريقك ومفيش حاجة محتاجة هندسة عكسية.
مفاتيح idempotency في كل حتة
على كل route بيعدّل بيانات. منطق إعادة المحاولة بتاعك، وطابور at-least-once بتاعك، والنتورك الوحش بتاعك، كله يبقى مشكلة حد تاني — تحديدًا، مشكلة unique index.
جرّب قبل ما تنشر
POST /v1/simulate بيشغّل contact على القمع كتجربة ويرجّع المسار وكل رسالة هيبعتها. حطه في الـ CI لو حابب: القمع رسم بياني، والرسم البياني ممكن يتّست.
سيرفر MCP
وجّه agent ناحية /mcp وسيبه يكتب ويفحص القمعات. الأدوات اللي بتقدر تبعت محتاجة تأكيد صريح ومحجوبة بكوتة، فـ prompt متقرأ غلط مش هيتحول لخمسين ألف إيميل.
Webhooks صادرة
موقّعة، ومعاد المحاولة بـ backoff، على الأقل مرة. نفس مفردات الأحداث اللي التقارير بتستخدمها، فمخزن البيانات بتاعك واللوحة بتاعتك مش هيختلفوا على معنى "delivered".
محو بيوصلالآخر فعلاً
طلب الحذف بيشيل الـ contact وتاريخ رسايله من هنا وبينتشر لكل الخدمات الشقيقة اللي معاها نسخة. طلب واحد، نتيجة واحدة، وحاجة تشاور عليها لما حد يسأل.
الحدّ فين
ClickSomo عنده ليست بريدية وسجل ما فعلته الليستة دي. هي مش قاعدة بيانات المستخدمين بتاعتك ومش بتحاول تبقى: الـ contact عمره ما يحمل كلمة مرور، عمره ما يسجّل دخول، وعمره ما يبقى حساب. المستخدمين بتوعك عايشين في منتجك؛ والـ contacts عايشين هنا، والاتنين بيتوصلوا ببعض بإيميل والأحداث اللي تختار تبعتها.
الفصل ده مقصود، وهو سبب إن نموذج الموافقة شغال. إنت الـ data controller لمستخدمينك؛ إحنا بنعالج نيابةً عنك. أي تصميم فيه أداة تسويق بتبقى عنStore الهوية من غير ما حد يحس، ده تصميم مستحيل يتفك لاحقًا، وهو بالظبط الفشل اللي التصميم ده اتبنى علشان يتجنبه.
النسخة العملية: ابعت الأحداث، وابعت الخصائص اللي عايز تعمل segmentation عليها، وسيب كل حاجة تانية في مكانها. لو لقيت نفسك بتدفع الـ schema بتاعتك كلها هنا، فالسيgment اللي بتحاول تبنيه غالبًا query في قاعدة بياناتك المفروض يوصلك كخاصية boolean واحدة.