Vue d'ensemble de la politique d'acceptation
Comprendre quels contrôles ticket s'appliquent avant qu'une soumission puisse compter dans le challenge.
La politique d'acceptation est le garde-fou entre l'extraction OCR et la logique de récompense. Elle décide si un ticket est éligible à poursuivre selon les données qu'OmniLab a pu lire et selon les règles que vous avez configurées pour le challenge.
Politique d'acceptation vs politique de validation
Ces deux idées travaillent ensemble, mais elles ne désignent pas la même chose :
| Couche | Ce qu'elle décide | Sortie typique |
|---|---|---|
Acceptance Policy | Si les données du ticket satisfont les exigences du challenge. | Passe ou échoue |
Validation Policy | Ce qui arrive ensuite à un ticket conforme. | VALID immédiatement ou PENDING pour revue manuelle |
Un ticket peut donc échouer avant même qu'un opérateur ne le voie. C'est pour cela que le design de politique compte autant.
Où se situe l'acceptation dans le flux de statuts
Ce que la politique peut vérifier
Dans l'écran actuel du builder, Receipt Acceptance Policy se concentre sur Field Requirements, avec des contrôles spécifiques par champ pour :
AmountDateMerchantZip Code
Ces exigences peuvent ensuite porter des règles plus fines, comme des montants minimum et maximum, des marchands autorisés ou restreints, le mode correspondance exacte, ainsi que des codes postaux autorisés ou restreints.
Selon le setup du challenge, la validation de politique peut aussi faire référence à des contrôles plus larges comme l'âge du ticket, la fenêtre de soumission, et le seuil de confiance OCR.
Les bonnes questions à se poser
Avant d'activer les toggles, posez-vous ces questions :
- Quels champs doivent toujours être présents pour que la logique de récompense soit fiable ?
- La campagne est-elle ouverte à tous les marchands ou seulement à un réseau partenaire ?
- Faut-il un seuil minimum de dépense, un plafond, ou les deux ?
- Le challenge est-il limité à un réseau de magasins ou à une zone géographique ?
- Les cas limites doivent-ils partir chez un opérateur ou échouer tout de suite ?
Exemple
Supposons une promesse de campagne du type : « Dépensez au moins 25 EUR chez les enseignes beauté partenaires ce week-end pour débloquer une pochette. »
Une politique cohérente nécessite souvent :
Amountrequis, avecMin Amount = 25Merchantrequis, limité à la liste partenaireDaterequis, afin de fiabiliser le timing d'achat- éventuellement
Zip Codesi seules certaines implantations sont éligibles
Ce que la politique d'acceptation ne fait pas
La politique d'acceptation ne décide pas :
- quelle récompense débloquer
- combien de fois une récompense peut encore être gagnée
- si les opérateurs peuvent forcer un déblocage de stock
- quel template d'e-mail est envoyé
Ces décisions vivent dans les rules, winning options, global outcome rules et notifications.
Liens utiles
Configurer les champs requis
Choisir quelles données extraites sont obligatoires.
Configurer les règles de montant
Appliquer des seuils minimum et maximum dans la politique.
Configurer les règles marchand
Autoriser ou bloquer des enseignes et gérer le matching exact.
Politique de validation : manuel ou automatique
Décider ce qui se passe après le passage de la politique.
Configurer les notifications pour un challenge ticket de caisse
Voir quels types de notifications sont les plus utiles pour les receipt games, puis continuer dans les guides Platform.
Configurer l'âge du ticket et la fenêtre de soumission
Contrôler l'ancienneté autorisée d'un ticket et le délai laissé au participant pour l'envoyer.