Non, Web Extend n'est pas requis. C'est Smart Insight qui collecte vos données de vente auprès de sources extérieures.

Le chargement échoue. C'est un champ obligatoire. Le fichier doit être corrigé et envoyé à nouveau.

Le chargement échoue. C'est un champ obligatoire. Le fichier doit être corrigé et envoyé à nouveau.

Nous créons un pseudo contact pour cette commande (en fait toutes les commandes de ce type sont rattachées à un pseudo contact). Ce contact apparaîtrait comme généré sur les écrans Smart Insight et ne pourrait être associé à aucun contact dans l'application Emarsys.

Non. Cela dupliquerait la commande et on serait obligé de charger à la fois le pseudo contact et l'autre dans le contact réel. C'est vous qui devez corriger le fichier, et de notre côté il nous faut refaire un chargement complet. Vous êtes supposés aviser le Support du chargement de fichier problématique, et nous nous occupons ensuite du nouveau chargement.

Une commande avec un un ID de client absent de la base de données de contact Emarsys sera quand même chargée sur l'entrepôt de données, et le contact lié sera généré avec seulement un ID de client et marqué comme généré dans Cycle de vie client. En utilisant le filtre généré, ce contact peut être séparé de ceux pour lesquels on a pu établir un lien entre le fichier de commandes et la base de données de contact.

Oui. Si l'identifiant client unique est ajouté à un contact qui a été chargé en tant que généré auparavant, il deviendra un contact valide au prochain chargement de données.

• commande L'ID de commande de la commande dans laquelle cet article a été acheté.
• date La date d'achat.
• client L'ID du client qui a fait l'achat. Il faut que cela soit des données de contact provenant de la base de données Emarsys.
• article L'ID du produit qui a été acheté.
• c_sales_amount Le montant total des ventes de cet article (c'est-à-dire prix à l'unité * quantité).
• quantité Le nombre d'articles achetés.

YYYY-MM-DD est préféré. Si HH:MM:(SS) est aussi envoyé, l'heure ne sera pas prise en compte.

Il est possible d'ajouter des champs personnalisés au fichier de ventes tant que le nom de fichier commence par le préfixe c_ (par ex. c_brand, c_webshop). Veuillez noter que l'ordre des colonnes est important. Les colonnes peuvent être envoyées dans n'importe quel ordre, à condition que cet ordre soit toujours le même. Les fins de colonnes ne doivent pas contenir de lignes vides.

Non, les fichiers que nous chargeons contiennent le prix total pour les articles (par ex. 2 articles coûtent 5 EUR en tout). Aucun prix unitaire n'est affiché et de tels calculs ne sont pas pris en charge dans SI.

Non, le processus de chargement s'interrompt et le chargement du fichier de vente échoue intégralement. C'est à vous de réparer cette erreur et à nous ensuite de charger à nouveau le fichier.

Ils seront chargés en tant que leads (contacts n'ayant encore rien acheté). S'ils ne sont pas identifiables (ne peuvent être associés à aucun contact Emarsys) ils seront générés comme leads avec une source de lead inconnue et un état du cycle de vie de nouveau lead.

S'il n'y a aucun en-tête dans le fichier, la première ligne sera perdue car elle comptera comme en-tête. L'en-tête est nécessaire.

Non, car dans ce cas le chargement échouerait. Nous ne créons des produits inconnus que quand l'ID de produit pour une commande manque au catalogue produit. Le fichier doit être corrigé et envoyé à nouveau.

Soit :

• le catalogue produit initial contenant tous les produits + les deltas quotidiens avec les changements, ou bien
• le catalogue produit complet chaque jour, ou bien encore
• un retour quotidien avec les produits commandés ce jour-là ?

Vous devez charger votre catalogue produit complet à chaque fois, pour assurer la cohérence.

Ces colonnes sont nécessaires pour SI, seul l' itemID est obligatoire.

• article (chaîne) L'ID unique utilisé dans votre système pour identifier un article. C'est l'ID auquel toutes les scripts de collecte de données et de rendu se référeront.
• titre (chaîne) Le nom du produit.
• catégorie (liste des niveaux de hiérarchie) Désigne la catégorie à laquelle un article donné appartient (par ex. Électronique>Téléphones>iPhone|Télécommunication>Smart Phones>iPhone). Une hiérarchie peut comprendre 5 catégories maximum, mais il n'y a pas de limite au nombre de hiérarchies pouvant être incluses.

Le chargement échoue. Le fichier doit être corrigé et envoyé à nouveau.

Le chargement échoue. Le fichier doit être corrigé et envoyé à nouveau.

Les fichiers sont chargés un par un (par ordre alphabétique), la dernière instance de l'article écrasera donc toutes les précédentes.

L'article sera chargé et affiché avec produit inconnu comme ID produit sur le deuxième graphique de l'écran Achats antérieurs. Dans ce cas, nous créons un produit dans la base de données Emarsys avec uniquement un ID produit, et aucune autre donnée associée. Notez que si un article n'est pas inclus dans le catalogue produit, il sera aussi un produit inconnu.

Ces articles seront chargés, mais ils n'apparaîtront sous aucune des catégories sur l'écran Achats antérieurs.

Si un article déjà chargé précédemment revient dans un nouveau fichier, le vieil article sera écrasé par le nouveau (par ex. catégorie de produit modifiée ou correction dans le nom de l'article).

Par défaut, c'est le premier niveau (supérieur) mais n'importe quel niveau de la hiérarchie de catégorie peut être choisi pour visualisation. Toutefois, veuillez noter que le niveau spécifié ne peut changer d'un article à l'autre (s'il est réglé pour le niveau 2 de la catégorie, cela s'applique à tous les articles sans exception).

Les remboursements eux-mêmes ne sont pas ajoutés au nombre total de commandes, mais les remboursements complets affectent cet indicateur car les commandes complètement remboursées ne sont pas incluses dans le nombre total de commandes. En règle générale, toute commande ou partie de commande dont le montant de vente est positif est ajoutée au nombre total de commandes, tandis que celles ayant un montant de vente négatif ou nul ne le sont pas.

Quand vous soumettez les articles ou commandes retournés, utilisez toujours les IDs de commande, de client et d'article de la commande originale et fournissez une valeur négative dans les champs c_sales_amount et les champs de quantité. Veuillez vous assurer de remplir les champs dans votre fichier de données de vente de cette manière, sinon les remboursements ne seront pas correctement représentés dans vos rapports.

Exemple

Voici comment la commande originelle est chargée dans le fichier de vente :

Une semaine plus tard le client décide de retourner 2 articles, ce qui doit être reporté dans le fichier de vente comme suit :

Ces deux parties de commande seront ensuite agrégée en une seule commande dont la valeur totale sera 45, tandis que la date de commande restera inchangée (c'est-à-dire que nous conservons la date de la commande originale).

Sur l'écran Impact sur le revenu les commandes ne sont pas agrégées. Chaque commande contribue au revenu du jour auquel elle a été passée. Si nous prenons l'exemple ci-dessus, les 100 Euros seront ajoutés au revenu total du 15 octobre, tandis que le remboursement de -55 Euros sera reporté au 22 octobre.

Bien sûr. Veillez simplement à bien suivre la convention de nomination du fichier de vente, c'est-à-dire à nommer le fichier selon le modèle sales_items*.csv. En d'autres termes, le nom de fichier doit commencer par la chaîne sales_item et son extension doit être .csv, tandis que vous devez remplacer l'astérisque par un nombre de caractères de votre choix.

En ce qui concerne le score de cycle de vie, toute commande positive compte comme une activité, même si elle est retournée plus tard. Par exemple, si vous chargez une commande avec un montant de ventes positif pour n'importe lesquels de vos Nouveaux acheteurs, ces derniers deviendront et resteront des Acheteurs actifs même si la commande est plus tard remboursée, complètement ou partiellement. Veuillez toutefois noter que les commandes ayant une valeur négative ou nulle n'affectent pas le score de cycle de vie de vos clients.

Les retours et les remboursements ne sont pas pris en compte dans le calcul du nombre d'achats ou de la date de dernier achat. Ils ne comptent pas non plus comme un engagement, donc ne sont pas pris en compte dans le calcul du dernier engagement.

En général, les remboursements n'affectent que le rendement total du contact et donc son état d'acheteur.

Le panier moyen est calculé en divisant le total de tous les montants de ventes par le nombre de commandes sur une période donnée. Les remboursements sont pris en compte dans le calcul du montant de ventes total.

Au moment du calcul de la Dépense totale à vie et de l'état d'acheteur, toutes les commandes sont prises en compte, indépendamment de la valence positive ou négative de leur valeur agrégée.

Le score monétaire est calculé en additionnant les achats sur une période définie. S'agissant des retours, c'est la date de commande originelle qui importe. Si celle-ci tombe en dehors de la période, la commande ne sera pas prise en compte dans le calcul du Score monétaire (ni de la dépense totale et de l'état d'acheteur), même si la transaction de retour a lieu pendant la période en question.

Nous alignerons la date d'inscription de ces contacts sur celle de la première commande dans SI. Cela n'affectera pas le côté Emarsys puisque nous n'envoyons pas de message retour à Emarsys à partir de SI, donc le champ de date d'inscription personnalisé restera vide dans l'application Emarsys.

La date d'inscription de ces contacts sera celle définie par la Date/date créée de première inscription. Le champ d'inscription personnalisé ne sera pas appliqué au dernier engagement dans ce cas.

Ce contact a été supprimé mais ses données de clic demeurent. Ce contact apparaîtra sur la page de cycle de vie Lead, son état de cycle de vie dépendra de la date de clic et la source de lead sera marquée comme inconnue.

Ces filtres peuvent être utilisés pour créer des segments comme la dépense totale ou le nombre d'achats sur une période donnée et/ou pour un produit donné. Ces filtres diffèrent des deux autres aux noms similaires qu'on trouve sur le cycle de vie client (la Dépense totale à vie et le Total des achats à vie) parce qu'alors que ceux-ci fonctionnent à partir de données de contact, ces deux-là utilisent les données d'achat. Les contacts qui s'inscrivent et achètent le même jour sont considérés comme des leads le premier jour et ne deviennent des clients que le deuxième jour.

Toutefois, leurs commandes seront chargées sur l'entrepôt de données dès le premier jour, alors qu'ils sont encore considérés comme des leads par le système. Cela peut entraîner une légère différence numérique entre les segments créés avec ces filtres similaires.

Les champs "catégories principales prédites" et identifiant unique (qui identifie l'achat) ont la même valeur pour 2 contacts. Vous devez amender l'identifiant unique pour l'un de ces contacts sous l'onglet Autre dans l'application Emarsys, ou bien supprimer le contact inutile dans la commande pour permettre le chargement de contact.