Cet article vous explique comment Emarsys se connecte à votre base de données afin de générer et d'exécuter des requêtes pour obtenir le contenu personnalisé pour les campagnes email avec Relational Data.
Quand Emarsys ouvre-t-il une connexion à votre base de données ?
Emarsys établit une connexion à votre base de données avec Relational Data Service (RDS) lorsque vous avez soit
- utiliser les fonctionnalités de Relational Data, , par exemple : lancer des campagnes email avec la personnalisation Relational Data ou utiliser un segment Relational Data dans un programme Automation Center,
- navigué dans l'interface utilisateur (IU) de la plateforme marketing Emarsys pour recueillir des métadonnées, ou
- importé des données à l'aide de l' API Relational Data.
Différents groupements de connexion
Relational Data utilise des groupements de connexion distincts pour éviter toute interférence entre la segmentation, la personnalisation et l'importation de données. Cette logique garantit qu'un segment lent ne peut pas bloquer l'importation de données via l'API Relational Data.
Durée de la connexion ouverte : Emarsys tente de fermer les connexions le plus rapidement possible, si un groupement de connexions n'a pas été utilisé pendant un certain temps.
Délai de connexion : Tous les connecteurs ont un délai de connexion configuré de cinq secondes.
Exception : Amazon Redshift a un délai d'attente de 15 secondes.
Comment générer et exécuter des requêtes pour la personnalisation ?
Une fois la connexion établie avec votre base de données, Emarsys peut générer et exécuter des requêtes pour obtenir un contenu personnalisé.
Exemple de cas d'utilisation
Pour vous expliquer comment exécuter des requêtes, nous utiliserons un cas d'utilisation réel et sa base de données comme exemple.
Une compagnie aérienne souhaite envoyer à ses contacts, dans le cadre de campagnes email personnalisées, des offres spéciales de vente incitative assorties de recommandations en fonction de la ville de destination et de la date d'arrivée. La campagne d'upsell est envoyée avec des offres personnalisées de services à acheter, comme la location de voitures ou la réservation d'hôtels à prix réduits dans la ville de destination, avant la date d'arrivée.
Exemple de contenu d'un email de vente incitative :
Sur la base des informations de contact, nous déterminons dans quelle ville le contact se rend, à quelle heure et quel service est disponible pour lui au meilleur prix dans la devise locale, pour la durée de service appropriée dans cette ville, par exemple :
Bonjour,
Nous avons vu que vous vous rendrez à Vienne le <date_of_arrival>.
Saviez-vous que vous pouvez acheter les services suivants à prix réduit ?
<service_name> at <company_name> <price> <currency> <service_duration>
Mise en place de la base de données
Les bases de données relationnelles stockent les données dans des tableaux, qui sont constitués de colonnes nommées et de lignes de données. Les lignes sont également appelées relations, d'où leur nom. Pour notre exemple de cas d'utilisation, vous avez les données de réservation de vos clients dans votre table de réservations (Colonnes : contact_id, booking_id, date_of_arrival, destination_city). Les services de vente incitative peuvent être obtenus à partir d'une vue appelée upsell_services. (Colonnes : service_type, service_name, company_name, city, price, currency, price_duration, availability). Vous pouvez également stocker des informations sur votre contact dans la base de données de contacts intégrée d'Emarsys. Avec le service Relational Data, Emarsys peut se connecter à vos propres bases de données (externes – qui doivent être préconfigurées). Pour plus de détails, cliquez ici.
Voir upsell_services
Pour cet exemple de requête, nous utilisons la vue appelée upsell_services.
| service_type | service_name | company_name | ville | price | monnaie | price_duration | disponibilité |
|---|---|---|---|---|---|---|---|
| rent_a_car | Louer une voiture | ViaRent | Vienna | 10 | L'euro | heure | oui |
| rent_a_car | Louer une voiture | BerliRent | Berlin | 14 | L'euro | heure | non |
| rent_a_car | Louer une voiture | KaiRent | Le Caire | 6 | Livre égyptienne | heure | oui |
| rent_a_car | Louer une voiture | LDRent | Londres | 8 | Livre Sterling | heure | oui |
| hébergement | Hébergement | GreatHotelVienna | Vienna | 130 | L'euro | nuit | oui |
| rent_a_bike | Louer un vélo | TwoWheelsBerlin | Berlin | 4 | L'euro | heure | oui |
| rent_a_bike | Louer un vélo | TwoWheelsBerlin | Vienna | 2 | L'euro | heure | oui |
| hébergement | Hébergement | AwesomeHotel | Berlin | 150 | L'euro | Nuit | non |
| baggage_insurance | baggage_insurance | InsuranceLTD | Général | 12 | Euro | voyage | Oui |
Mise en place de champs de référence
Dans l'email, nous voulons utiliser la valeur de nom_du_service en fonction de la valeur de city et de son availability.
Pour ce faire, nous devons définir deux champs de référence, qui sont city et availability. Nous utilisons ces deux champs de référence ensemble pour identifier les valeurs pour la personnalisation.
ESL
Script pour obtenir le nom d'un service disponible situé à Vienne :rds.myconnection.upsell_services("Vienna","yes")[0].service_name
Demande de renseignements
Emarsys exécute la requête suivante pour obtenir la valeur de service_name où city = "Vienne" et availability = "oui" :
select distinct service_name from upsell_services where (city = "Vienna" AND availability = "yes") limit x
Définition d'une valeur par défaut
Si vous vous attendez à ce que certaines valeurs ne soient pas représentées dans votre vue et que vous voulez vous assurer que, même dans ce cas, vous avez un contenu, vous pouvez définir une valeur par défaut.
ESLrds.myconnection.upsell_services("Los_Angeles","yes")[0].service_name
Nous avons déjà configuré les champs de référence city et availability et nous avons ajouté la valeur par défaut "Général" pour le champ de référence city.
Vérifier si la valeur par défaut est nécessaire ?
Comme une valeur par défaut est définie avant d'exécuter la requête pour trouver le contenu personnalisé, nous vérifions d'abord s'il est nécessaire d'utiliser la valeur par défaut, en exécutant la requête suivante :
Demande de renseignementsselect distinct city from upsell_services where city = "Los_Angeles" limit 1
Résultat : Vide
Si le résultat de la requête de la valeur par défaut est vide, Emarsys doit utiliser la valeur par défaut plutôt que la valeur originale.
Demande de renseignementsselect distinct service_name from upsell_services where (city = "General" AND availability = "yes") limit x
Résultat : Pas vide
Si le résultat de la requête de la valeur par défaut n'est pas vide, Emarsys exécute la requête avec la valeur originale (et non avec la valeur par défaut).
Demande de renseignementsselect distinct service_name from upsell_services where (city = "Los_Angeles" AND availability = "yes") limit x
Personnalisation de plusieurs contacts
En général, Emarsys peut regrouper et exécuter des requêtes pour 500 contacts par source de personnalisation (table ou vue). Toutefois, si le message contient plusieurs fois la même source avec différentes configurations (paramètres), la taille du lot est multipliée par le nombre de configurations différentes dans le message et elles sont regroupées. Chaque requête contiendra jusqu'à 1 000 groupes de paramètres dans la condition where.
Un groupe de paramètres contient plusieurs champs de référence pour un token de personnalisation.
Dans cet exemple, le champ contact.1234 contient les villes de destination de chaque contact :
rds.myconnection.upsell_services(contact.1234,"yes")[0].service_name
rds.myconnection.upsell_services(contact.1234,"no")[0].service_name
Il s'agirait d'un groupe de 2x500 paramètres, car même s'il provient de la même source (vue upsell_services), il a deux configurations différentes. Ainsi, pour les 500 contacts, Emarsys exécute une requête contenant 1000 paramètres dans la condition where .
Demande de traitement par défautselect distinct city from upsell_services where (city = "Vienna") OR (city = "Los_Angeles") limit 2
Si le résultat de la requête par défaut n'est pas videselect distinct service_name from upsell_services where ((city = "Los_Angeles" AND availability = "yes") OR (city = "Vienna" AND availability = "yes")) limit x
Personnalisation de plusieurs paramètres
Si le message contient plusieurs fois la même source avec des configurations ou des paramètres différents, ils sont fusionnés en une seule requête.
ESL
rds.myconnection.upsell_services("Los_Angeles","yes")[0].service_name rds.myconnection.upsell_services("Los_Angeles","yes")[0].service_typeRequête
select distinct service_name, service_type from upsell_services where (city = "Los_Angeles" AND availability = "yes") limit xSi plusieurs sources sont utilisées dans la même campagne, elles ne sont pas fusionnées pour créer une seule requête. Chaque source individuelle aura sa propre requête.
Limitation des demandes de personnalisation
Nous utilisons une limite dans chaque requête. Lorsque vous utilisez le même ESL avec différents index, la limite est augmentée au lieu d'exécuter la requête plusieurs fois.
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_nameRequête
select distinct service_name from upsell_services where (city = "Los_Angeles" AND availability = "yes") limit 3Dans le cas de la balise ESL foreach, vous pouvez définir la limite vous-même, mais la limite maximale est 100. Si elle n'est pas définie, la limite est de 100 par défaut.
Répétition des requêtes
Si plusieurs ESL ou tokens de personnalisation sont présents dans vos campagnes avec plusieurs sources de personnalisation (table ou vue) et qu'au moins l'une d'entre elles ne fonctionne pas, toutes les requêtes sont réessayées et pas seulement la requête lente défectueuse.
Par exemple, supposons que la campagne contienne les éléments suivants :
rds.myconnection.upsell_services("Los_Angeles","yes")[0].service_name rds.myconnection.bookings(contact.1234,"Los_Angeles")[0].date_of_arrivalSi l'une des tables de réservation est lente et ne renvoie pas les résultats dans le délai imparti, les deux requêtes de personnalisation seront relancées. Par conséquent, les requêtes suivantes sont exécutées plusieurs fois dans votre base de données :
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 xBien entendu, si la campagne est envoyée à plusieurs contacts, les conditions peuvent être plus complexes que celles décrites ci-dessus.
La durée de création des requêtes de personnalisation Relational Data - FAQ
Quel est le délai pour les demandes de personnalisation Relational Data ?
Pour des performances optimales, les requêtes doivent être exécutées en moins de 500 ms.
Que faire lorsqu'une requête de personnalisation Relational Data est trop lente ?
L'optimisation de la durée des requêtes de personnalisation Relational Data est très similaire à l'optimisation des requêtes de modèles de segments relationnels. La création d'une requête de segment bien optimisée nécessite une connaissance approfondie du type de base de données que vous utilisez, des données que vous stockez dans votre base de données, du cas d'usage que vous essayez de créer ainsi qu'une compréhension générale de l'optimisation des requêtes.
Nous vous recommandons vivement de consulter un expert si vous rencontrez des problèmes de performance.
- Lorsque vous créez une requête de personnalisation, tenez toujours compte des éléments suivants :
- Quelle sera la taille de l'ensemble des résultats ?
- Quelle est la taille de l'ensemble de données que la requête analyse pour déterminer les résultats ?
- Après avoir considéré ces éléments, vous pouvez décider :
- Utilisation ou non d'index : Selon le type de base de données que vous utilisez, cela peut être différent, mais en général, vous devriez envisager d'utiliser des index. La plupart du temps, avec des ensembles de données plus importants, les index peuvent améliorer les performances. Vous devez également indexer les champs de référence.
- Utilisation ou non de fonctions dans la clause où : Certaines fonctions peuvent augmenter considérablement la durée des requêtes car elles peuvent entraîner des balayages de table involontaires. Avant de les utiliser, nous vous recommandons d'étudier leur impact sur les performances.
- Ce que vous devez vraiment inclure dans la requête : Évitez d'utiliser sélectionner *. Au lieu de cela, incluez les colonnes spécifiques dont vous avez besoin individuellement.
- Utilisation d'une jointure au lieu de sous-requêtes corrélées : La plupart du temps, lorsqu'on travaille avec de grands ensembles de données, les jointures ont de meilleures performances que les sous-requêtes corrélées.
- Comment utiliser les jointures : Les "jointures" peuvent également prendre beaucoup de temps. Ne joignez pas des tables inutilisées, et essayez toujours de joindre des champs indexés. En outre, les champs que vous rejoignez doivent avoir le même type de données.
- Utilisation ou non de caractères génériques : L'utilisation de caractères génériques ralentira certainement votre requête, en particulier pour les tableaux volumineux. Essayez de l'éviter si vous le pouvez.