SaaS- och produktteam
Din produkt vet saker som inget marknadsföringsverktyg kan observera
Vem som avslutade onboarding och vem som fastnade på steg tre. Vem som bjöd in en kollega. Vem som nådde gränsen två gånger den här veckan. Vem som inte öppnat grejen på två veckor. Vart och ett av dem är en bättre utlösare än något som härletts ur ett e-postöppnande, och alla ligger två rader kod från att bli det.
Händelser är hela integrationen
POST /v1/events med din egen token: ett namn du valt, en kontakt, en payload, en idempotensnyckel. Det är hela kopplingen. Ingen SDK att hålla uppdaterad, ingen mappningsskärm och inget vokabulär från oss som du måste översätta din produkt till.
Varje händelse landar på kontaktens tilläggsvänliga logg, och därifrån är den tre saker på en gång. En utlösare, så att en tratt startar när den anländer. Ett villkor, så att ett segment kan säga "har gjort detta de senaste fjorton dagarna" eller, mer användbart, "inte har gjort det". Och ett mål, så att en sekvens tar slut i samma stund som någon gör det den puffade dem mot.
Det tredje är det som gör livscykelsmeddelanden uthärdliga att ta emot. Puffen för att färdigställa ditt konto bör sluta existera i samma sekund som kontot är färdigställt, och i de flesta verktyg gör den inte det, för sekvensen och produkten pratar inte med varandra.
- ⚡Utlösare
api_event—signup.completed, abonnemangfree. - 2Skicka mejlDen enda sak att göra först. Inte en rundtur i elva funktioner.
- 3Vänta 2 dagar
wake_atpå körningen. Inget köat, inget att plocka isär om du skriver om det här imorgon. - ?VillkorHar
project.createdkommit fram? Nej → hjälp-grenen. Ja → målet nedan. - 4Hjälp-grenEtt meddelande som erbjuder just det de inte gjorde. Sedan en ny väntan.
- 5Mål
project.createdkommer fram. Körningen avslutas. Ingen mer onboarding-post, någonsin, för den här personen.
Dina händelsenamnDin definition av aktiverad
Fem trattar
Livscykeln, i den ordning den faktiskt sker
1 · Aktivering
Utlösare: registrering. Två eller tre meddelanden, vart och ett om en åtgärd, vart och ett med ett mål som avslutar sekvensen när åtgärden sker. Den mest värdefulla tratten du kommer att bygga, och den som är mest värd att skriva om tre gånger.
2 · Avstannandet
Utlösare: segment_enter — registrerad, ingen meningsfull händelse på sju dagar. Ett meddelande som frågar i stället för att tala om, och ett som erbjuder något konkret. Sedan stopp. Ett fjärde meddelande till någon som ignorerat tre är ett meddelande till ingen.
3 · Expansionstillfället
Utlösare: en händelse som betyder att de får värde — når gränsen, bjuder in en tredje kollega, exporterar för andra gången. Detta är det enda tillfälle då ett uppgraderingsmeddelande är välkommet, och det är ett tillfälle din produkt kan namnge exakt.
4 · Förnyelse och betalningspåminnelser
Utlösare: date_field före förnyelse, eller en betalningshändelse. Notis, påminnelse och — om en betalning misslyckas — en kort sekvens som stannar i samma stund den lyckas. Målnoder är inte valfria i betalningspåminnelser; de är skillnaden mellan en påminnelse och trakasserier.
5 · Återvinning
Utlösare: segment_enter — sagt upp sig eller vilande i sextio dagar. Två meddelanden, ärliga sådana, sedan en tagg och tystnad. Det som förändrats sedan de lämnade är ett bättre meddelande än en rabatt.
Och den interna
notify_team talar om för en människa när ett konto värt en människa passerar en gräns. En tratt behöver inte sluta i ett e-postmeddelande till en kund; ibland är rätt åtgärd att be någon på din sida plocka fram telefonen.
Ingen säger upp sig med flit. De slutar bara öppna den.
Varför en utvecklare faktiskt kan gilla det här
Delarna som spelar roll när det är du som integrerar
Inga privata endpoints
Varje skärm går att bygga från det publika API:et, eftersom det inte finns någon annan sort. Om du vill bädda in en kampanjrapport i din egen admin står inget i vägen och inget behöver reverse-engineeras.
Idempotensnycklar överallt
På varje muterande rutt. Din retry-logik, din at-least-once-kö och ditt flakiga nätverk blir alla någon annans problem — närmare bestämt ett unikt index problem.
Simulera innan du skeppar
POST /v1/simulate kör en torrkörning av en kontakt genom en tratt och returnerar vägen och vart och ett av de meddelanden den skulle skicka. Lägg in den i CI om du vill: en tratt är en graf, och en graf kan testas.
En MCP-server
Rikta en agent mot /mcp och låt den skriva och kontrollera trattar. Verktyg som kan skicka kräver en uttrycklig bekräftelse och begränsas av kvot, så en feltolkad prompt kan inte bli femtio tusen e-postmeddelanden.
Webhooks ut
Signerad, försökt igen med backoff, minst en gång. Samma händelsevokabulär som rapporterna använder, så att ditt warehouse och din dashboard inte är oense om vad "levererad" betyder.
Radering som faktiskt når fram
En begäran om radering tar bort kontakten och deras meddelandehistorik här och sprider sig till varje syster-tjänst som höll en kopia. En begäran, ett utfall, och något du kan peka på när du blir tillfrågad.
Var gränsen går
ClickSomo har en utskickslista och det listan gjorde. Den är inte din användardatabas och försöker inte vara det: en kontakt bär aldrig en autentiseringsuppgift, loggar aldrig in och blir aldrig ett konto. Dina användare bor i din produkt; kontakter bor här, och de två knyts samman av en e-postadress och de händelser du väljer att skicka.
Den separationen är medveten, och det är därför samtyckesmodellen fungerar. Du är personuppgiftsansvarig för dina användare; vi behandlar på din vägnar. En design där ett marknadsföringsverktyg i smyg blir identitetslagret är en som inte går att reda ut senare, och det är exakt det fel den här är byggd för att undvika.
Den praktiska versionen: skicka händelserna, skicka attributen du vill segmentera på, och låt allt annat vara där det är. Om du upptäcker att du trycker in hela ditt schema här är segmentet du försöker bygga förmodligen en fråga i din egen databas som i stället borde anlända som ett enda booleskt attribut.