Non, Web Extend n'est pas requis. C'est Smart Insight qui collecte vos données de vente à partir de sources externes.

Le chargement échoue. Il s'agit d'un champ obligatoire. Le fichier doit être corrigé et renvoyé.

Le chargement échoue. Il s'agit d'un champ obligatoire. Le fichier doit être corrigé et renvoyé.

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ît comme généré sur les écrans de Smart Insight et ne peut être associé à aucun contact dans l'app Emarsys.

Non. Cela dupliquerait la commande, l'une serait chargée pour le pseudo-contact et l'autre pour le vrai contact. Vous devez corriger le fichier et nous procédons à un nouveau chargement du fichier complet. Vous devez communiquer le chargement du fichier qui pose problème au Support et nous procédons à un nouveau chargement.

Une commande comportant un ID client ne figurant pas dans la base de données de contact Emarsys sera chargée dans l'entrepôt de données et le contact correspondant sera généré avec seulement un ID client Smart Insight interne et sera signalé comme generated dans Cycle de vie client. La valeur du champ number_of_purchase des contacts marqués comme generated est fixée à 1. Bien qu'un seul contact puisse effectuer plusieurs achats, ces contacts ne peuvent pas être fusionnés en une seule entrée dans la base de données. En utilisant le filtre generated et en fixant la valeur du champ number_of_purchase à 1, ce contact peut être séparé de ceux pour lesquels la connexion a pu être établie entre le fichier des commandes et la base de données de contacts.

Oui. Lorsque l'identifiant client unique est ajouté à un contact qui avait été chargé comme « généré », ce contact devient « valide » lors du prochain chargement de données.

• commande - L'identifiant de la commande contenant l'article acheté.
• horodatage - La date de l'achat.
• client - L'identifiant du client ayant effectué la commande. Il doit s'agir des données de contact de la base de données Emarsys.
• article - L'identifiant du produit qui a été acheté.
• prix - Le prix total de l'article.
• quantité - Le nombre d'articles achetés.

De préférence, le format AAAA-MM-JJ. Si HH:MM:(SS) est également envoyé, l'heure ne sera pas prise en compte.

Il est possible d'ajouter des champs personnalisés au fichier de vente, à condition que le nom du champ 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, mais ce dernier doit toujours être le même. La fin des colonnes ne doit pas contenir de lignes vides.

Non, les fichiers que nous chargeons contiennent le prix total des articles (par ex 2 articles coûtent 5 EUR au total). Aucun prix unitaire n'est affiché et nous ne prenons pas en charge ce type de calcul dans SI.

Non, le processus de chargement s'arrête et rien n'est chargé à partir du fichier de vente. Vous devez corriger l'erreur et nous devons à nouveau charger le fichier après correction.

Ils sont chargés en tant que leads (contacts qui n'ont encore rien acheté). S'ils ne sont pas identifiables (ils ne peuvent être mis en correspondance avec aucun contact Emarsys), ils sont « générés en tant que leads » avec une source lead « inconnue » et un statut de cycle de vie de « nouveau lead ».

S'il n'y a pas d'en-tête dans le fichier, la première ligne sera perdue, car elle sera considérée comme un en-tête. L'en-tête est obligatoire.

Non, le chargement échouerait. Nous ne créons des « produits inconnus » que lorsqu'il manque l'ID produit d'une commande dans le catalogue produit. Le fichier doit être corrigé et renvoyé.

Pour que les calculs et les analyses Smart Insight fonctionnent correctement, le catalogue produit doit inclure les articles référencés dans le fichier de données de vente. Sinon, les rapports Smart Insight contiendront des produits inconnus et ce problème ne pourra pas être résolu, même en téléchargeant à nouveau votre fichier de données produits historiques.

Les nouveaux achats sont affichés dans les segments de cycle de vie et les rapports Smart Insight uniquement après un chargement de données effectué le jour suivant (les nouveaux achats ne seront pas enregistrés même si vous effectuez plusieurs chargements de données de vente le jour où les chargements de données sont effectués).

Le filtre Total dépensé pour la sélection est une exception. Ce filtre Smart Insight est basé sur des données d'achat en temps réel, contrairement au filtre Valeur à vie totale dépensée qui est calculé après le chargement des données qui a lieu le jour suivant. Pour cette raison, nous recommandons de combiner le filtre Total dépensé pour la sélection avec d'autres attributs d'achat . Sa combinaison avec les attributs de contact tels que l'étape du cycle de vie client peut conduire à des résultats inappropriés. Dans ce cas, nous recommandons de combiner le filtre Étape du cycle de vie client avec Valeur à vie totale dépensée.

Si vous utilisez notre solution Chargement de données de vente en bloc, vous devez formater votre fichier de données de vente conformément aux exigences du fichier CSV Données de vente standard.

Si vous utilisez notre solution Chargement de données de vente en bloc, vous pouvez vérifier vos chargements de données de vente et les notifications de qualité des données sur la page Gestion > Chargement de données de vente.

Au choix :

• Catalogue produit initial contenant tous les produits + les deltas quotidiens avec les changements, ou
• Catalogue produit complet chaque jour, ou
• Flux quotidien uniquement avec les produits qui ont été commandés ce jour-là.

Nous vous conseillons de télécharger votre catalogue produit complet à chaque fois, pour des raisons de cohérence.

Les colonnes suivantes sont requises pour SI, seul l'itemID est obligatoire.

• article (chaîne) L'identifiant unique utilisé dans votre système pour identifier un article. Il s'agit de l'ID auquel tous les scripts de collecte de données et de rendu se référeront.
• titre (chaîne) Le nom du produit.
• categorie (liste de niveaux hiérarchiques) Décrit la catégorie à laquelle appartient un article donné (par ex. Électronique>Téléphones>iPhone|Télécommunication>Téléphones intelligents>iPhone). Une hiérarchie peut comprendre au maximum 5 catégories, mais le nombre de hiérarchies est illimité.

Le chargement échoue. Le fichier doit être corrigé et renvoyé.

Le chargement échoue. Le fichier doit être corrigé et renvoyé.

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

L'article sera chargé et affiché en tant qu'« ID produit » produit inconnu sur le deuxième graphique de l'écran Achats passés. Dans ce cas, nous créons un produit dans la base de données Emarsys en lui attribuant uniquement un ID produit, sans aucune autre donnée. Notez que si un article n'est pas inclus dans le catalogue produit, il s'agira également d'un produit inconnu.

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

Si un article précédemment chargé apparaît dans un nouveau fichier, l'ancien article sera remplacé par le nouveau (par ex. une catégorie de produit modifiée ou une correction du nom de l'article).

Par défaut, il s'agit du premier niveau (supérieur), mais vous pouvez choisir de visualiser n'importe quel niveau de la hiérarchie des catégories. Toutefois, veuillez noter que le niveau spécifié ne peut pas changer d'un article à l'autre (s'il est défini pour le niveau de catégorie 2, cela s'applique à tous les articles).

Les remboursements ne sont pas ajoutés au nombre total de commandes, mais les remboursements complets ont une incidence sur cet indicateur, car les commandes entièrement 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 d'achat est positif est ajoutée au nombre total de commandes, tandis que celles dont le montant d'achat est négatif ou nul ne le sont pas.

Lorsque vous soumettez des articles ou des commandes retournés, utilisez toujours les ID de la commande, du client et de l'article de la commande originale et indiquez une valeur négative dans les champs c_sales_amount et quantity. 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

La commande originale est téléchargée dans le fichier de vente de la façon suivante :

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

Ces deux parties de la commande seront ensuite regroupées en une seule commande d'une valeur totale de 45, tandis que la date de la commande restera inchangée (c'est-à-dire que nous conservons la date de la commande initiale).

L'écran Impact sur les revenus ne permet pas d'agréger les commandes. Chaque commande contribue aux revenus du jour où elle a été passée. Si nous reprenons l'exemple ci-dessus, les 100 euros seront ajoutés aux revenus totaux du 15 octobre, tandis que le remboursement de -55 euros apparaîtra dans le rapport du 22 octobre.

Bien sûr. Veillez simplement à respecter la règle de dénomination des fichiers de vente, c'est-à-dire à nommer le fichier en utilisant le modèle sales_items*.csv. En d'autres mots, le nom de fichier doit commencer par la chaîne sales_item et son extension doit être .csv, tandis que vous pouvez remplacer l'astérisque par un certain nombre de caractères de votre choix.

Pour ce qui est du scoring du cycle de vie, toute commande positive compte comme une activité, même si elle est retournée ultérieurement. Par exemple, si vous téléchargez une commande avec un montant de vente positif pour l'un de vos nouveaux acheteurs, ils deviendront et resteront des acheteurs actifs, même si la commande est remboursée ultérieurement, totalement ou partiellement. Veuillez noter, cependant, que les commandes ayant une valeur négative ou nulle n'affectent pas votre scoring du cycle de vie client.

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

D'une manière générale, les remboursements n'affectent que le chiffre d'affaires total issu du contact et donc son statut d'acheteur.

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

Le calcul de la Dépense totale sur la durée de vie et du statut de l'acheteur prend en compte toutes les commandes, que leur valeur agrégée soit positive ou négative.

Le Score monétaire est calculé en additionnant les achats sur une période définie. Pour les retours, c'est la date de la commande initiale qui compte. Si cette date se situe en dehors de la période, la commande ne sera pas prise en compte dans le calcul du Score monétaire (de même que le total des dépenses et le statut de l'acheteur), même si la transaction de retour a été effectuée au cours de cette période.

Nous définirons la date d'inscription de ces contacts comme étant la même que la date de la première commande dans SI. Cela n'aura pas d'incidence côté Emarsys puisque nous ne renvoyons pas de données de SI vers Emarsys. Le champ personnalisé de date d'inscription restera donc vide dans l'app Emarsys.

La date d'inscription de ces contacts sera la date définie par la Date de création/Date de la première inscription. Dans ce cas, le champ personnalisé d'inscription ne s'appliquera pas au dernier engagement.

Le contact a été supprimé, mais ses données de clic ont été conservées. Ce contact apparaîtra sur la page Cycle de vie lead, son statut de cycle de vie dépendra de la date du clic et la source lead sera Inconnue.

Ces filtres peuvent être utilisés pour créer des segments tels que le total des dépenses ou le nombre d'achats sur une période donnée et/ou pour un produit donné. Ces filtres sont différents des deux filtres de la page Cycle de vie client dont les noms sont similaires (Dépense totale sur la durée de vie et Achats totaux sur la durée de vie) : les premiers utilisent les données de contact, alors que les seconds utilisent les données d'achat. Les contacts qui s'inscrivent et effectuent des achats le même jour sont considérés comme des leads le premier jour et ne deviennent des clients que le deuxième jour.

Cependant, leurs commandes seront chargées dans l'entrepôt de données dès le premier jour, alors que, du point de vue du système, ce sont des leads. Les chiffres peuvent donc être légèrement différents entre les segments créés avec ces filtres similaires.

Si les données de vente sont incorrectes (c'est-à-dire si les commandes sont en double), vos résultats ou les écrans Smart Insight seront faussés. Dans ce cas, nous vous recommandons de recharger vos données Smart Insight. Pour plus d'informations, voir Recharger les données dans Smart Insight.