Triggers uitvoeren: planning, voorbeeld en uitvoeringslogboek

Zodra uw triggerregels zijn ingesteld, vindt alles rond het uitvoeren ervan plaats op het tabblad Delivery. Dit artikel behandelt de dagelijkse planning, handmatige uitvoeringen en tests op één lid, de beveiligingen voor rusturen en frequentielimieten, hoe Preview werkt, en de volledige referentie van het uitvoeringslogboek inclusief kolommen, statuswaarden en backend-skipredenen.

Inhoud

• Plannen en uitvoeren
• Rusturen en frequentielimieten
• De volledige geschiktheidsketen
• Preview
• Referentie van het uitvoeringslogboek
• Kolommen
• Statuswaarden
• Backend-skipredenen

Plannen en uitvoeren

Alles rond het uitvoeren van triggers vindt plaats op het tabblad Delivery: de dagelijkse planning, rusturen, frequentielimieten en het paneel Execute Triggers. Sommige elementen binnen het tabblad behouden de bewoording Execution (bijvoorbeeld Execution Results, Execution Run en Executed At).

Het tabblad Delivery: dagelijkse planning, rusturen, frequentielimieten en handmatige uitvoeringen op één plek.

Dagelijkse planning

• Stel een tijdstip en tijdzone in op de configuratie en zet de planning aan of uit.
• De planning wordt gedeeld door alle studio's die de configuratie gebruiken.
• De scheduler controleert elke minuut op configuraties die aan de beurt zijn en voert alle actieve regels uit voor alle gekoppelde studio's.
• Een regel draait niet twee keer op dezelfde kalenderdag (in de lokale tijdzone van de studio). Als een regel vandaag al heeft gedraaid, of dat nu automatisch of handmatig was, wordt deze niet opnieuw uitgevoerd.

Handmatige uitvoering ("Run now")

• Voert de regel onmiddellijk uit voor de huidige studio. Dit verstuurt echte berichten. Er is geen ongedaan maken voor een verzonden bericht.
• Een handmatige uitvoering staat op zichzelf: deze dedupt niet tegen andere regels van de dagelijkse uitvoering.
• Als de regel vandaag al heeft gedraaid (automatisch of handmatig), wordt de handmatige uitvoering geblokkeerd om dubbele berichten te voorkomen.

Testen met één lid

• Voert de regel uit tegen één specifiek lid dat u kiest.
• U kiest het lid op basis van de customer ID, niet het ledennummer. Kopieer deze van het ledenprofiel: open het profiel en neem het nummer in de pagina-URL, bijvoorbeeld .../#/customermanagement/1562839240/overview betekent customer ID 1562839240.
• Omzeilt het matchen van voorwaarden: het lid wordt verwerkt ongeacht of het aan de voorwaarden voldoet.
• Verzendt altijd als Groep A, zonder het lid vast te zetten in een control-bucket, zodat de test nooit stilzwijgend in de controlegroep belandt.
• Gebruik dit om de kanaalopzet en sjablonen end-to-end te verifiëren voordat u een regel activeert.

Rusturen en frequentielimieten

Twee van de berichtbeveiligingen zijn globale instellingen, geconfigureerd op het tabblad Delivery en gedeeld door alle studio's die aan de configuratie zijn gekoppeld. (De andere twee beveiligingen, de cooldown per regel en de dedup bij meerdere matches, worden behandeld in Triggerregels aanmaken en bewerken.)

Rusturen. Stel een begin- en eindtijd in de tijdzone van de studio in. Bereiken die over nacht lopen werken (22:00 tot 07:00 loopt over middernacht heen). Rusturen zijn uitgeschakeld als slechts een van de twee tijden is ingesteld, of als begin en einde identiek zijn.

Wat er gebeurt tijdens rusturen. Berichten die aan de beurt komen terwijl het venster open is, worden niet weggegooid: ze worden in de wachtrij geplaatst en verzonden zodra het rusturenvenster openstaat voor verzending (dat wil zeggen zodra het venster eindigt). De trigger-editor waarschuwt u wanneer een geconfigureerd uitvoeringstijdstip binnen een actief rusturenvenster valt, en het paneel voor de dagelijkse planning toont dezelfde waarschuwing voor de dagelijkse uitvoering. Gebeurtenisgestuurde leadtriggers (de New-Lead welcome) zijn niet onderhevig aan rusturen en worden onmiddellijk verzonden.

Volgorde van beveiligingen. Voor elke uitvoering worden de beveiligingen in een vaste volgorde geëvalueerd: rusturen, vervolgens de dagelijkse limiet, vervolgens de wekelijkse limiet, en vervolgens de cooldown per regel.

Dagelijkse en wekelijkse frequentielimieten. Voortschrijdende limieten per lid: een maximaal aantal Engage-berichten per dag (voortschrijdend venster van 24 uur) en per week (voortschrijdend venster van 7 dagen). Elke limiet heeft een eigen aan/uit-schakelaar op het tabblad Delivery. Als een lid een limiet al heeft bereikt, worden verdere berichten overgeslagen.

De limieten zijn globaal per lid over alle Engage-triggers, niet per trigger geteld, dus een lid dat eerder in het venster al een bericht van een andere regel ontving, kan voor deze regel worden weggefilterd door de limiet. Eén uitvoering telt als één bericht, ook als het over meerdere kanalen uitgaat. De vensters zijn voortschrijdend (de laatste 24 uur en de laatste 7 dagen), geen kalenderdagen of -weken.

Zie ook: Triggerregels aanmaken en bewerken (Berichtbeveiligingen, Prioriteit en oplossing bij meerdere matches).

De volledige geschiktheidsketen

Een lid kan aan elke voorwaarde voldoen die u hebt geschreven en toch niets ontvangen, omdat voorwaarden slechts één stap zijn. Voor elke uitvoering past Engage deze keten in volgorde toe:

1. Doelgroep — actief lid, voormalig lid of lead.
2. Communicatiestop — leden die zich hebben afgemeld (geen Nieuwsbrief-toestemming) worden verwijderd.
3. Contracttype — het insluit/uitsluit-filter op contracttype van de regel.
4. Uw voorwaarden — de voorwaardevelden op de regel.
5. Bereikbaarheid op het geselecteerde kanaal — WhatsApp en SMS hebben een telefoonnummer nodig, Email heeft een e-mailadres nodig.

Ontbrekende contactgegevens op het geselecteerde kanaal is de meest voorkomende reden waarom een matchend lid niets krijgt. Eén kanttekening bij de voorwaardestap: een voorwaarde matcht alleen leden die daadwerkelijk een waarde voor dat veld hebben. Een lid zonder waarde wordt door elke operator uitgesloten, inclusief negaties, dus een lid zonder betaalmethode matcht niet met "payment method is not Direct Debit". Om leden zonder waarde te bereiken, gebruikt u een expliciete "is empty"-voorwaarde waar het veld die aanbiedt.

Preview

Preview controleert het bereik van een regel voordat er iets wordt verzonden.

• Preview evalueert het huidige concept van de regel zoals u het in de editor hebt, niet de laatst opgeslagen versie.
• Het geeft het totale aantal matchende leden terug en een voorbeeldlijst met naam, churn risk-band en belangrijkste bezoekmetrieken.
• Preview is een realtime-momentopname: het toont alleen wie op dit moment aan de voorwaarden voldoet, op basis van de datasnapshot van de huidige dag (ledenmetrieken verversen eenmaal per dag).
• U kunt de volledige gepagineerde lijst met matchende leden laden, wat helpt in grote studio's.

Een telling van 0 is geen probleem. Als Preview 0 leden toont, betekent dat alleen dat er vandaag niemand matcht. Het betekent niet dat de regel defect is of dat er morgen niemand zal matchen: leden komen in en uit de voorwaarden naarmate hun data verandert, bijvoorbeeld wanneer een drempel voor contractafloop 's nachts wordt overschreden of een lid de dormancy-drempel overschrijdt.

Gebruik Preview om drempels af te stemmen voordat u activeert. Als een Dormancy-regel de helft van de studio matcht, is de drempel waarschijnlijk te strak voor een nuttige campagne; verhoog de waarde voor dagen sinds het laatste bezoek en bekijk het voorbeeld opnieuw.

Preview toont wie aan de voorwaarden voldoet. Het simuleert de beveiligingen niet, dus het werkelijke aantal berichten dat in een uitvoering wordt verzonden, kan lager liggen zodra cooldowns, frequentielimieten, rusturen, dedup en de A/B-controlegroep worden toegepast. Behandel het voorbeeld als "wie is geschikt", niet "wie wordt aangeschreven".

Referentie van het uitvoeringslogboek

Elk beoordeeld lid krijgt een regel, zodat u altijd kunt reconstrueren waarom iemand wel of niet is gecontacteerd. Het tabblad Delivery toont overzichtskaarten (Totaal gematcht, Groep A, Groep B) en een resultatentabel per lid. Resultaten kunnen worden gefilterd op datumbereik, uitvoering, trigger, kanaal en A/B-groep, en geëxporteerd naar CSV.

Delivery-resultaten: één regel per beoordeeld lid, met Path (One-way of Agent), kanaal, A/B-groep en uitkomst.

Kolommen

Statuswaarden

Elke verzendpoging eindigt in precies een van de onderstaande uitkomsten, weergegeven in de kolom Status. De kolom Path ernaast toont Agent (bezorgd via de MagicAI Chat-agent) of Enkele reis (rechtstreeks verzonden), en is leeg voor overgeslagen en control-rijen.

Dit zijn de bezorglogboekstatussen die door engineering zijn bevestigd (de message-status-set van de ml-backend). Elk beoordeeld lid produceert één regel per uitvoering met zijn uitkomst. De status "Skipped (backend)" draagt een reden-veld op het tweede niveau dat de precieze oorzaak benoemt (zie Backend-skipredenen hieronder). Rijkere bezorgrapporten per verzending (een status Succeeded, Failed of Pending per bericht met de foutreden) zijn gepland voor een latere release, niet voor go-live. De exacte bewoording op het scherm voor de minder voorkomende statussen is geverifieerd tegen de GA-UI.

Backend-skipredenen

Wanneer de status "Skipped (backend)" is, legt het reden-veld uit waarom het bezorgsysteem het bericht heeft achtergehouden:

Zie ook: WhatsApp instellen voor Engage. Zie ook: Impact Analysis.