Hygiène CSV du lookup en masse avant campagne : normaliser, dédupliquer et budgéter

Le marketing veut une liste. La finance voit une rafale de débits lookup qui ne collent pas aux SMS envoyés ensuite. Le lookup en masse n’est pas verser une feuille dans l’API. L’hygiène précède la dépense : normaliser en E.164, dédupliquer, respecter le cache de type de ligne périmé, plafonner le portefeuille. Qui saute l’hygiène traite les numéros morts comme des incidents de livraison, les lignes dupliquées comme « couverture » et une étiquette mobile vieille comme vérité de routage.

IOSOR range le lookup à côté de la messagerie sur un ledger prepaid white-label. Catalogue live signifie que le contrôle est prêt ; in setup n’est pas une porte de production qu’on cache.

Colonnes CSV dont finance et ops ont besoin

Finance et ops doivent ouvrir le même CSV et lire la même histoire. Colonnes minimales : E.164 normalisé, saisie brute, horodatage lookup, type de ligne, hit de cache ou contrôle frais, montant débité, décision d’envoi (envoyer / sauter / revérifier), id de campaign ou de lot. Une étiquette « mobile » sans horodatage est une opinion, pas une preuve.

E.164 et déduplication avant la dépense lookup

Normalisez et dédupliquez avant de dépenser du lookup. La même ligne écrite +1…, 001… et format local se débite trois fois. Normalisez en E.164, dédupliquez sur ce numéro, puis appelez lookup live. Les lignes poubelle (trop courtes, lettres, chaînes de test) se jettent à l’import, on ne les interroge pas en « inconnu ».

Risque de cache de type de ligne périmé

Un type de ligne en cache est un signal de routage horodaté, pas un tatouage. Le mobile d’hier peut être une plage VoIP aujourd’hui. Un cache périmé envoie l’OTP dans une plage morte ou ajoute de la friction à qui a porté hier. Vous payez quand même la ligne lookup et le segment gaspillé. Le TTL est une règle produit, pas un goût de base. Ne cachez pas « inconnu » comme mobile.

Plafonds de budget et cadence d’export

Les plafonds de budget appartiennent au lot, pas à « on rapprochera plus tard ». Posez un plafond de lignes et d’montant par run de lookup ; la cadence d’export (quotidienne ou à la clôture du lot) précède le blast, ce n’est pas une surprise de fin de mois. Vers USD 1,000+, la dépense évitable et les seaux d’âge de cache entrent en revue plus dense.

Signaux d’alerte

• Lookup en masse sans normaliser
• Le même E.164 débité deux fois pour des variantes de format
• « Mobile » périmé traité comme vérité de routage
• Inconnu caché comme mobile
• CSV sans plafond de lignes ni de montant
• Lookup rapproché de l’envoi seulement en fin de mois
• Hygiène promise alors que le canal est in setup
• Erreurs client qui nomment des marques amont

Commencer avec IOSOR

Prenez le CSV de la campagne de la semaine dernière. Normalisez chaque ligne en E.164, jetez les déchets, dédupliquez sur le numéro normalisé, puis un seul lookup. Plafonnez le lot par nombre de lignes et montant prepaid avant le blast. Exportez le même fichier que finance et ops ouvriront : type de ligne, hit de cache, débit, décision send ou skip.

• Gestion des retenues sur portefeuille prépayé pour les requêtes de recherche…
• lookup du numéro avant l’envoi
• Simulation de la latence et des erreurs DLR dans les tests locaux

À retenir — IOSOR

Faites : l’hygiène avant l’argent lookup. Les variantes de format d’une ligne sont un débit. Un type de ligne en cache a un horodatage ; un mobile périmé n’est pas une vérité de routage.

Ne faites pas : verser la feuille dans l’API et rapprocher en fin de mois. Les doublons ne sont pas de la couverture. Unknown mis en cache comme mobile est une fuite prepaid.