Race-Conditions
Eine Race-Condition tritt auf, wenn ein Ergebnis von der Reihenfolge oder dem Timing mehrerer Ereignisse abhängt. Wenn beispielsweise die gewünschte Reihenfolge der Ereignisse „Event A“ und dann „Event B“ ist, aber manchmal „Event A“ zuerst kommt und manchmal „Event B“ zuerst – dann spricht man von einer Race-Condition. Dies kann zu unerwarteten Ergebnissen oder Fehlern führen, da diese Ereignisse um den Zugriff auf gemeinsame Ressourcen oder Daten konkurrieren.
In Braze können Race-Conditions auftreten, wenn mehrere Aktionen gleichzeitig auf Basis von Nutzerdaten oder Events ausgelöst werden. Wenn beispielsweise eine Nutzer:in mehrere Campaigns triggert (wie die Anmeldung für einen Newsletter oder einen Kauf), erhält sie die Nachrichten möglicherweise nicht in der richtigen Reihenfolge.
Arten von Race-Conditions
Die häufigsten Arten von Race-Conditions können auftreten, wenn Sie Folgendes tun:
- Neue Nutzer:innen ansprechen
- Mehrere API-Endpunkte verwenden
- Aktionsbasierte Trigger und Zielgruppenfilter abgleichen
- Den Trigger „Interact with Step“ verwenden
Betrachten Sie die folgenden Szenarien und implementieren Sie Best Practices, um diese Race-Conditions zu vermeiden.
Szenario 1: Targeting neuer Nutzer:innen
In Braze tritt eine der häufigsten Race-Conditions bei Nachrichten auf, die sich an neu erstellte Nutzer:innen richten. Die erwartete Reihenfolge der Ereignisse ist:
- Ein:e Nutzer:in wird erstellt;
- Dieselbe Person wird sofort für eine Nachricht angesprochen, führt ein angepasstes Event aus oder protokolliert ein angepasstes Attribut.
In einigen Fällen wird jedoch das zweite Ereignis zuerst ausgelöst. Das bedeutet, dass versucht wird, eine Nachricht an eine:n Nutzer:in zu senden, die/der noch nicht existiert. Infolgedessen erhält die Person die Nachricht nie. Dies gilt auch für Events oder Attribute, bei denen versucht wird, das Event oder Attribut in einem Nutzerprofil zu protokollieren, das noch nicht erstellt wurde.
Bei In-App-Nachrichten muss die In-App-Nachricht auf dem Gerät der nutzenden Person geladen werden, bevor sie ausgelöst werden kann. Wenn das Trigger-Ereignis Teil des Onboarding-Prozesses ist oder die Person das Segment für das angepasste Event im Rahmen ihrer ersten Sitzung verlässt, ist es wahrscheinlich, dass sie die In-App-Nachricht nicht sehen wird.
In-App-Nachrichten
Bei In-App-Nachrichten kann die Situation komplexer sein. Eine In-App-Nachricht muss an das SDK zugestellt und dort zwischengespeichert werden – typischerweise zu Beginn einer Sitzung –, bevor sie ausgelöst werden kann. Wenn das Trigger-Ereignis Teil des Nutzer:innen-Erstellungsprozesses ist oder wenn die In-App-Nachrichten-Campaign zugestellt wird, bevor die Person die Zielgruppenkriterien erfüllt (oder nachdem sie diese nicht mehr erfüllt), kann es sein, dass sie die In-App-Nachricht während ihrer ersten Sitzung nicht sieht.
Best Practices
Verzögerungen einführen
Nachdem ein:e neue:r Nutzer:in erstellt wurde, können Sie eine Verzögerung hinzufügen, bevor Sie gezielte Campaigns oder Canvases senden. Diese zeitliche Verzögerung ermöglicht es, das Nutzerprofil zu erstellen und alle relevanten Attribute zu aktualisieren, die die Berechtigung zum Empfang der Nachricht bestimmen können.
Zum Beispiel können Sie nach der Registrierung einer Person in Ihrer App ein Werbeangebot nach 24 Stunden senden. Oder wenn Sie eine:n Nutzer:in erstellen oder ein angepasstes Attribut protokollieren, können Sie eine einminütige Verzögerung hinzufügen, bevor Sie in Ihrem Prozess fortfahren, um diese Race-Condition zu vermeiden.
Sie können diese Verzögerung auch im Braze SDK für das spezifische angepasste Event hinzufügen, das eine:n neue:n Nutzer:in dazu veranlasst, ein Canvas zu betreten.
Szenario 2: Verwendung mehrerer API-Endpunkte
Wir verwenden asynchrone Verarbeitung, um Geschwindigkeit und Flexibilität zu maximieren. Das bedeutet, dass wenn API-Aufrufe separat an uns gesendet werden, wir nicht garantieren können, dass sie in der Reihenfolge verarbeitet werden, in der sie gesendet wurden.
Es gibt einige Szenarien, in denen mehrere API-Endpunkte ebenfalls zu dieser Race-Condition führen können, zum Beispiel wenn:
- Separate API-Endpunkte verwendet werden, um Nutzer:innen zu erstellen und Canvases oder Campaigns auszulösen
- Mehrere separate Aufrufe an den
/users/track-Endpunkt gemacht werden, um angepasste Attribute, Events oder Käufe zu aktualisieren
Wenn Nutzerinformationen über den /users/track-Endpunkt an Braze gesendet werden, kann die Verarbeitung gelegentlich einige Sekunden dauern. Das bedeutet, wenn gleichzeitig Anfragen an den /users/track- und Messaging-Endpunkte wie /campaign/trigger/send gestellt werden, gibt es keine Garantie, dass die Nutzerinformationen vor dem Senden einer Nachricht aktualisiert werden.
Wenn Nutzerattribute und Events in derselben Anfrage gesendet werden (entweder über /users/track oder über das SDK), verarbeitet Braze Attribute vor Events oder bevor versucht wird, eine Nachricht zu senden.
Best Practices
Bei der Verwendung mehrerer Endpunkte Anfragen nacheinander senden
Wenn Sie mehrere Endpunkte verwenden, können Sie versuchen, Ihre Anfragen zeitlich zu staffeln, sodass jede Anfrage abgeschlossen ist, bevor die nächste beginnt. Dies kann die Wahrscheinlichkeit einer Race-Condition verringern. Wenn Sie zum Beispiel Nutzerattribute aktualisieren und eine Nachricht senden müssen, warten Sie zunächst, bis das Nutzerprofil vollständig aktualisiert ist, bevor Sie eine Nachricht über einen Endpunkt senden.
Wenn Sie eine geplante Nachrichten-API-Anfrage senden, müssen diese Anfragen separat sein, und Nutzer:innen müssen erstellt werden, bevor die geplante API-Anfrage gesendet wird.
Schlüsseldaten mit dem Trigger einschließen
Anstatt mehrere Endpunkte zu verwenden, können Sie die Nutzerattribute und Trigger-Eigenschaften in einem einzigen API-Aufruf über den campaign/trigger/send-Endpunkt einschließen.
Wenn diese Objekte mit dem Trigger eingeschlossen werden, werden die Attribute zuerst verarbeitet, bevor die Nachricht ausgelöst wird, wodurch potenzielle Race-Conditions vermieden werden. Beachten Sie, dass Trigger-Eigenschaften das Nutzerprofil nicht aktualisieren, sondern nur im Kontext der Nachricht verwendet werden.
Den POST: Track users (sync)-Endpunkt verwenden
Verwenden Sie den /users/track/sync/-Endpunkt, um angepasste Events und Käufe synchron aufzuzeichnen und Nutzerprofilattribute zu aktualisieren. Die Verwendung dieses Endpunkts zum gleichzeitigen Aktualisieren von Nutzerprofilen in einem einzigen Aufruf kann helfen, potenzielle Race-Conditions zu vermeiden.
This endpoint befindet sich derzeit in der Beta-Phase. Kontaktieren Sie Ihre:n Braze Account Manager:in, wenn Sie an der Teilnahme an der Beta interessiert sind.
Szenario 3: Abgleich von aktionsbasierten Triggern und Zielgruppenfiltern
Eine weitere häufige Race-Condition kann auftreten, wenn Sie eine aktionsbasierte Campaign oder ein Canvas mit demselben Trigger wie dem Zielgruppenfilter konfigurieren (z. B. ein geändertes Attribut oder ein ausgeführtes angepasstes Event). Die Nutzer:innen befinden sich zum Zeitpunkt des Trigger-Events möglicherweise nicht in der Zielgruppe, was bedeutet, dass sie die Campaign nicht erhalten oder das Canvas nicht betreten.
Best Practices
Zielgruppe nach einer Verzögerung prüfen
Um die Verwendung von Zielgruppenfiltern zu vermeiden, die die Trigger-Kriterien enthalten, empfehlen wir, Ihre Zielgruppe vor der Zustellung zu überprüfen. Beispielsweise können Sie Zustellungsvalidierungen verwenden in Canvas-Nachrichtenschritten als zusätzliche Prüfung, um zu bestätigen, dass Ihre Zielgruppe die Zustellungskriterien zum Zeitpunkt des Nachrichtenversands erfüllt. Sie können auch Exit-Kriterien für Canvas nutzen, um Nutzer:innen jederzeit während der User Journey zu entfernen, wenn sie Ihre Kriterien erfüllen.
Für Campaigns können Sie Exit-Events verwenden, damit Campaigns mit einem Trigger-Event Nachrichten an Nutzer:innen abbrechen, die das Exit-Event während der Verzögerung ausführen.
Eindeutige Filter mit dem Trigger-Event verwenden
Beim Konfigurieren Ihrer Filter möchten Sie möglicherweise einen redundanten Filter „für alle Fälle“ hinzufügen. Diese Redundanz kann jedoch zu weiteren Problemen führen. Vermeiden Sie stattdessen nach Möglichkeit die Verwendung von Filtern, die den Trigger enthalten. Dies ist der sicherste Weg, um eine Race-Condition zu vermeiden.
Wenn beispielsweise Ihr Campaign-Trigger „Hat einen Kauf getätigt“ lautet und Ihr Zielgruppenfilter „Hat einen beliebigen Kauf getätigt“ ist, kann diese Redundanz eine Race-Condition verursachen.
Zielgruppenfilter vermeiden, die voraussetzen, dass das Trigger-Event aktualisiert wurde
Diese Best Practice ähnelt der Vermeidung redundanter Filter mit dem Trigger-Event. In der Regel schlägt ein Filter fehl, der davon ausgeht, dass das Trigger-Event im Nutzerprofil aktualisiert wurde.
Liquid-Abbrüche verwenden (nur Attribute)
Verwenden Sie in Campaigns und Canvas-Schritten Liquid-Abbrüche, um zu vermeiden, dass Zielgruppenfilter verwendet werden, die die Trigger-Attribute beim Entry-Zeitplan enthalten. Angenommen, Sie haben ein Array-Attribut „Lieblingsfarben“ und möchten alle Nutzer:innen ansprechen, die das Attribut-Array mit einem beliebigen Wert aktualisieren und außerdem die Farbe „Blau“ im Array nach Abschluss des Updates enthalten haben. Wenn Sie in diesem Beispiel die Zielgruppenfilter verwenden, stoßen Sie auf eine Race-Condition und verpassen Nutzer:innen, die „Blau“ zum ersten Mal zum Array hinzufügen.
In diesem Fall können Sie eine Trigger-Verzögerung in einer Campaign implementieren oder einen Verzögerungsschritt in Canvas verwenden, um dem Nutzerprofil Zeit zum Aktualisieren zu geben, und dann die folgende Liquid-Abbruchlogik verwenden:
{%assign colors={{custom_attribute.$(Favorite Color)|split:”,”}}%}
{%unless colors contains ‘Blue’%}
{%abort_message(Blue not present)%}
{%endunless%}
Bestätigen, wie Nutzerdaten verwaltet werden
Wenn während der Canvas-Entry-Auswertung eine Race-Condition auftritt, können Nutzer:innen ein Canvas betreten, für das sie nicht vorgesehen waren. Beispielsweise könnte das Profil der Nutzer:innen so eingestellt sein, dass es in der Zielgruppe enthalten ist, und anschließend aktualisiert werden, nachdem das Canvas die Nutzer:innen in die Warteschlange gestellt hat, sodass sie nicht mehr für die Zielgruppe berechtigt sind.
Wenn Nutzer:innen das Canvas-Entry-Event mehrmals innerhalb derselben Sekunde auslösen, erlaubt Braze nur einen Entry für diese Sekunde (auch wenn Re-Entry aktiviert ist). Dies verhindert doppelte Eintritte, sodass die Gesamtzahl der Canvas-Eintritte niedriger sein kann als die Gesamtzahl der Trigger-Events.
Wir empfehlen zu bestätigen, wie Nutzerdaten verwaltet und aktualisiert werden, insbesondere wann und wie bestimmte Attribute aktualisiert werden, z. B. über SDK, API, Batch-API und andere Methoden. Dies kann dabei helfen, zu identifizieren und zu klären, warum Nutzer:innen eine Campaign oder ein Canvas betreten haben, im Vergleich dazu, wann das Nutzerprofil aktualisiert wurde.
Szenario 4: Verwendung des Triggers „Mit Schritt interagieren“
Wenn in einem Canvas auf einen Nachrichtenschritt direkt ein Aktionspfade-Schritt folgt, der den Trigger „Mit Schritt interagieren“ verwendet, kann eine Race-Condition auftreten. Da Nutzer:innen mit einer Nachricht interagieren können, sobald sie zugestellt wurde, ist es möglich, dass Nutzer:innen die getrackte Aktion abschließen, bevor sie offiziell in den Aktionspfade-Schritt eintreten.
In diesem Fall registriert der Aktionspfade-Schritt die Interaktion nicht, da er nur Events auswertet, die nach dem Eintritt in den Schritt auftreten. Das bedeutet, dass Nutzer:innen möglicherweise einen unbeabsichtigten Pfad entlang geleitet werden.
Ein Canvas sendet eine Push-Benachrichtigung in einem Nachrichtenschritt, gefolgt von einem Aktionspfade-Schritt, der prüft, ob die Nutzer:innen diese Push-Benachrichtigung öffnen. Wenn Nutzer:innen die Push-Benachrichtigung sofort nach dem Empfang öffnen (bevor sie in den Aktionspfade-Schritt eintreten), wird das Öffnungs-Event möglicherweise nicht erfasst. Die Nutzer:innen könnten dann fälschlicherweise den Pfad „hat nicht geöffnet“ entlang geleitet werden, obwohl sie tatsächlich mit der Nachricht interagiert haben.
Best Practices
Engagement über ein angepasstes Event tracken
Vermeiden Sie es, „Mit Schritt interagieren“ direkt nach einem Nachrichtenschritt zu verwenden, wenn Nutzerinteraktionen voraussichtlich schnell erfolgen. Tracken Sie Engagement stattdessen über ein angepasstes Event (zum Beispiel ausgelöst von der App oder Website nach der Interaktion) und werten Sie dieses Event in einem nachgelagerten Schritt aus. So wird sichergestellt, dass das Event erst erfasst wird, nachdem die Nutzer:innen in den Schritt eingetreten sind.
Branches vermeiden, die von einer Interaktion abhängig sind
Gestalten Sie Ihren Canvas so, dass eine verpasste sofortige Interaktion das Nutzererlebnis nicht beeinträchtigt. Vermeiden Sie zum Beispiel kritische Verzweigungsentscheidungen, die ausschließlich davon abhängen, ob die Interaktion im nächsten Schritt erfasst wird, oder fügen Sie eine Folgelogik hinzu, die die Pfade der Nutzer:innen korrigieren kann.