Dieser Artikel beschreibt, wie Emarsys eine Verbindung zu Ihrer Datenbank herstellt, um Abfragen (Queries) zu generieren und auszuführen und so personalisierten Content für E-Mail-Kampagnen mit Relational Data zu erhalten.
Wann öffnet Emarsys die Verbindung mit Ihrer Datenbank?
Emarsys stellt die Verbindung zu Ihrer Datenbank über den Relational Data Service (RDS) her, wenn Sie entweder
- Relational Data Funktionen verwenden, z.B. E-Mail-Kampagnen mit Relational Data Personalisierung senden oder ein Relational Data Segment in einem Automation Center Programm verwenden
- im User Interface (UI) der Emarsys Marketing Plattform browsen, um Metadaten zu sammeln, oder
- Daten über das Relational Data API importieren.
Verschiedene Verbindungspools
Relational Data verwendet eigenständige Verbindungspools, um Interferenzen zwischen Segmentierung, Personalisierung und Datenimport zu vermeiden. Diese Logik stellt sicher, dass das Ausführen eines langsamen Segments den Datenimport über das Relational Data API nicht blockiert.
Verbindungslaufzeit: Wenn ein Verbindungspool eine Weile nicht verwendet wurde, ist Emarsys bemüht, die Verbindung so schnell wie möglich zu trennen.
Verbindungstimeout: Alle Connectors haben ein Verbindungstimeout von 5 Sekunden konfiguriert.
Ausnahme: Amazon Redshift hat ein Timeout von 15 Sekunden.
Wie werden Personalisierungsabfragen generiert und ausgeführt?
Sobald die Verbindung mit Ihrer Datenbank hergestellt ist, kann Emarsys Abfragen generieren und ausführen, um so personalisierten Content abzurufen.
Beispiel für einen Use Case
Um Ihnen zu zeigen, wie Abfragen ausgeführt werden, verwenden wir einen realen Use Case und die entsprechende Datenbank.
Ein Flugunternehmen möchte personalisierte E-Mail-Kampagnen nutzen, um spezielle Upsell-Angebote mit Empfehlungen an seine Kontakte zu senden; als Basis dienen die jeweilige Zielstadt der Reise und das Ankunftsdatum. Bei den personalisierten Angeboten in der Upsell-Kampagne handelt es sich um kostenpflichtige Services wie eine Autovermietung oder Hotelbuchung in der Zielstadt, die vor dem Ankunftsdatum zu herabgesetzten Preisen erworben werden können.
Beispiel für einen E-Mail Content mit Upsell-Ziel:
Auf Basis der Kontaktinformationen erkennen wir, wann ein Kontakt in welche Stadt reist; dann bestimmen wir, welche Services in dieser Zeit und für den gesamten Aufenthalt zum besten Preis in der lokalen Währung verfügbar sind, z.B.:
Hallo,
wir haben gesehen, dass Sie am <date_of_arrival> nach Wien reisen.
Wussten Sie, dass Sie folgende Services zu einem reduzierten Preis buchen können?
<service_name> bei <company_name> <price> <currency> <service_duration>
Ihre Datenbank einrichten
Relational Datenbanken speichern Daten in Tabellen, die aus beschrifteten Spalten und Zeilen mit Daten bestehen. Die Zeilen werden auch Relationen - oder Relations - genannt, daher der Name. Bei unserem Use Case Beispiel haben Sie die Buchungsdaten Ihrer Kunden in Ihrer Buchungstabelle (Spalten: contact_id, booking_id, date_of_arrival, destination_city). Die Upsell Services können aus einer Ansicht namens upsell_services abgerufen werden. (Spalten: service_type, service_name, company_name, city, price, currency, price_duration, availability). Informationen zu Ihren Kontakten speichern Sie auch in der Emarsys-eigenen Kontaktdatenbank. Mit dem Relational Data Service kann Emarsys eine Verbindung zu Ihren eigenen (externen) Datenbanken herstellen (die vorkonfiguriert werden muss); weitere Informationen erhalten Sie hier.
Ansicht "upsell_services"
Für dieses Beispiel einer Abfrage verwenden wir eine Ansicht namens upsell_services.
| service_type | service_name | company_name | city | price | currency | price_duration | availability |
|---|---|---|---|---|---|---|---|
| rent_a_car | Rent a car | ViaRent | Vienna | 10 | Euro | hour | yes |
| rent_a_car | Rent a car | BerliRent | Berlin | 14 | Euro | hour | no |
| rent_a_car | Rent a car | KaiRent | Cairo | 6 | Egyptian Pound | hour | yes |
| rent_a_car | Rent a car | LDRent | London | 8 | Pound | hour | yes |
| accomodation | Accomodation | GreatHotelVienna | Vienna | 130 | Euro | night | yes |
| rent_a_bike | Rent a bike | TwoWheelsBerlin | Berlin | 4 | Euro | hour | yes |
| rent_a_bike | Rent a bike | TwoWheelsBerlin | Vienna | 2 | Euro | hour | yes |
| accomodation | Accommodation | AwesomeHotel | Berlin | 150 | Euro | Night | no |
| baggage_insurance | baggage_insurance | InsuranceLTD | General | 12 | Euro | trip | yes |
Referenzfelder einrichten
In der E-Mail-Nachricht wollen wir den Wert für service_name verwenden, basierend auf dem Wert für city und availability.
Dafür müssen wir zwei Referenzfelder einrichten: city und availability. Um die Werte für die Personalisierung zu identifizieren, verwenden wir diese zwei Referenzfelder gemeinsam.
ESL
Script für den Namen eines verfügbaren Services in Wien:rds.myconnection.upsell_services("Vienna","yes")[0].service_name
Abfrage
Emarsys führt folgende Abfrage aus, um jenen Wert für service_name zu erhalten, bei dem die city = "Vienna" und die availability = "yes" ist.
select distinct service_name from upsell_services where (city = "Vienna" AND availability = "yes") limit x
Standardwert einrichten
Wenn Sie davon ausgehen, dass einige Werte in der Ansicht nicht enthalten sein werden, und Sie sicherstellen wollen, dass auch in diesem Fall Content erzeugt wird, können Sie einen Standardwert definieren.
ESLrds.myconnection.upsell_services("Los_Angeles","yes")[0].service_name
Die Referenzfelder city und availability haben wir bereits eingerichtet; nun fügen wir für das Referenzfeld city den Standardwert "General" hinzu.
Überprüfen, ob der Standardwert gebraucht wird
Nun, da der Standardwert definiert ist, überprüfen wir vor Ausführen der Abfrage für den personalisierten Content, ob wir den Standardwert überhaupt benötigen; dafür führen wir folgende Abfrage aus:
Abfrageselect distinct city from upsell_services where city = "Los_Angeles" limit 1
Ergebnis: leer
Wenn das Ergebnis der Standardwertabfrage leer ist, muss Emarsys den Standardwert statt des Originalwerts verwenden.
Abfrageselect distinct service_name from upsell_services where (city = "General" AND availability = "yes") limit x
Ergebnis: nicht leer
Wenn das Ergebnis der Standardwertabfrage nicht leer ist, führt Emarsys die Abfrage mit dem Originalwert (und nicht dem Standardwert) aus.
Abfrageselect distinct service_name from upsell_services where (city = "Los_Angeles" AND availability = "yes") limit x
Mehrere Kontakte personalisieren
Ganz allgemein kann Emarsys pro Personalisierungsquelle (Tabelle oder Ansicht) Abfragen für jeweils 500 Kontakte zusammenstellen und ausführen. Wenn eine Nachricht allerdings mehrmals ein und dieselbe Quelle mit unterschiedlichen Konfigurationen (Parametern) enthält, wird die Batchgröße mit der Anzahl der unterschiedlichen Konfigurationen in der Nachricht multipliziert und diese werden zusammengefasst. Jede der Abfragen enthält dann bis zu 1.000 Parametergruppen in der Bedingung where.
Eine Parametergruppe enthält mehrere Referenzfelder für ein Personalisierungs-Token.
In diesem Beispiel enthält das Feld contact.1234 die Zielstädte für den jeweiligen Kontakt:
rds.myconnection.upsell_services(contact.1234,"yes")[0].service_name
rds.myconnection.upsell_services(contact.1234,"no")[0].service_name
Das ergibt als Parametergruppe 2x500, denn obwohl die Quelle dieselbe ist (Ansicht upsell_services), hat sie zwei unterschiedliche Konfigurationen. Also führt Emarsys für die 500 Kontakte 1 Abfrage aus, die 1.000 Parameter in der Bedingung where enthält.
Abfrage für das Standard-Handlingselect distinct city from upsell_services where (city = "Vienna") OR (city = "Los_Angeles") limit 2
Wenn das Ergebnis der Standardabfrage nicht leer istselect distinct service_name from upsell_services where ((city = "Los_Angeles" AND availability = "yes") OR (city = "Vienna" AND availability = "yes")) limit x
Multiple Parameter personalisieren
Wenn die Nachricht mehrmals dieselbe Quelle mit unterschiedlichen Konfigurationen oder Parametern enthält, werden diese zu einer Abfrage zusammengefasst.
ESL
rds.myconnection.upsell_services("Los_Angeles","yes")[0].service_name rds.myconnection.upsell_services("Los_Angeles","yes")[0].service_typeAbfrage
select distinct service_name, service_type from upsell_services where (city = "Los_Angeles" AND availability = "yes") limit xWenn in einer Kampagne mehrere Quellen verwendet werden, werden diese nicht zu einer einzigen Abfrage zusammengefasst. Jede der Quellen hat ihre eigene Abfrage.
Limit bei Personalisierungsabfragen
Wir verwenden limit in jeder Abfrage. Wenn Sie dieselbe ESL mit unterschiedlichen Indizes verwenden, wird nicht die Abfrage mehrmals ausgeführt, sondern das Limit erhöht.
ESL
rds.myconnection.upsell_services("Los_Angeles","yes")[0].service_name rds.myconnection.upsell_services("Los_Angeles","yes")[1].service_name rds.myconnection.upsell_services("Los_Angeles","yes")[2].service_nameAbfrage
select distinct service_name from upsell_services where (city = "Los_Angeles" AND availability = "yes") limit 3Für das ESL-Tag foreach können Sie das Limit selbst definieren; das Maximallimit liegt jedoch bei 100. Ist das Limit nicht definiert, wird standardmäßig das Limit 100 verwendet.
Abfragen neuerlich ausführen ("Retries")
Wenn Ihre Kampagnen mehrere ESL oder Personalisierungs-Tokens mit multiplen Personalisierungsquellen (Tabellen oder Ansichten) enthalten und für zumindest eine davon das Zeitlimit überschritten wird, werden sämtliche Abfragen neu ausgeführt, nicht nur die betroffene Abfrage.
Nehme wir an, Sie haben Folgendes in Ihrer Kampagne:
rds.myconnection.upsell_services("Los_Angeles","yes")[0].service_name rds.myconnection.bookings(contact.1234,"Los_Angeles")[0].date_of_arrivalWenn eine der Buchungstabellen langsam ist und die Ergebnisse nicht in der erwarteten Zeit zurückgibt, werden beide Personalisierungsabfragen erneut ausgeführt. Daher werden folgende Abfragen in Ihrer Datenbank mehrmals ausgeführt:
select distinct service_name from upsell_services where (city = "Los_Angeles" AND availability = "yes") limit x select distinct date_of_arrival from bookings where (user_id = 2 AND destination_city = "Los_Angeles") limit xBitte beachten Sie: Wenn die Kampagne an mehrere Kontakte gesendet wird, können die Bedingungen komplexer sein als oben beschrieben.
Laufzeit von Relational Data Personalisierungsabfragen - häufig gestellte Fragen
Was ist das Zeitlimit für Relational Data Personalisierungsabfragen?
Um eine optimale Performance zu gewährleisten, sollten die Abfragen nach weniger als 500 ms fertiggestellt sein.
Was kann ich tun, wenn eine Relational Data Personalisierungsabfrage zu langsam ist?
Für das Optimieren der Laufzeit von Relational Data Personalisierungsabfragen gelten sehr ähnliche Regeln wie für das Optimieren von Abfragen auf Basis von Relational Segment Vorlagen. Das Erstellen einer wirklich optimierten Abfrage erfordert ein tiefes Verständnis des verwendeten Datenbanktyps, der Daten, die Sie in Ihrer Datenbank speichern, des Use Case, den Sie abbilden wollen, ebenso wie ein gewisses Maß an Erfahrung mit Abfrageoptimierungen.
Daher empfehlen wir dringend, bei Performanceproblemen einen Experten zu Rate ziehen.
- Wenn Sie eine Personalisierungsabfrage erstellen, sollten Sie Folgendes immer berücksichtigen:
- Wie groß wird das Result-Set sein?
- Wie groß ist das Dataset, das von der Abfrage gescannt wird?
- Wenn Sie sich darüber im Klaren sind, sollten Sie sich folgende Fragen beantworten:
- Will ich Indizes verwenden? Auch der verwendete Datenbanktyp ist hier ein Faktor, aber grundsätzlich sollten Sie die Verwendung von Indizes überlegen. Bei großen Datasets können Indizes die Performance verbessern. Auch Referenzfelder sollten indiziert werden.
- Will ich Funktionen in der WHERE-Klausel verwenden? Funktionen können die Abfragedauer signifikant verlängern, weil sie nicht beabsichtigte Tabellenscans triggern. Bevor Sie Funktionen verwenden, sollten Sie sich über deren Auswirkung auf die Performance informieren.
- Was will ich wirklich in die Abfrage einschließen? Vermeiden Sie die Verwendung von select *. Schließen Sie stattdessen genau die Spalten ein, die Sie auch tatsächlich benötigen.
- Will ich statt korrelierter Unterabfragen JOIN-Klauseln verwenden? Bei der Arbeit mit größeren Datasets zeigen JOIN-Klauseln eine bessere Performance als korrelierte Unterabfragen.
- Wie will ich JOINS verwenden? Auch JOINS können zeitaufwendig sein. Verknüpfen Sie keine Tabellen, die Sie nicht verwenden, und versuchen Sie, stets auf indizierten Feldern zu verknüpfen. Verknüpfte Felder sollten denselben Datentyp haben.
- Will ich Wildcards verwenden? Die Verwendung von Wildcards wird die Abfrage definitiv verlangsamen, ganz besonders bei großen Tabellen. Vermeiden Sie die Verwendung von Wildcards, wenn das möglich ist.