Calculez une tranche stable de déploiement progressif

Ce calculateur transforme l’identifiant stable d’un utilisateur, d’un compte, d’un appareil ou d’un locataire en l’une des 10,000 tranches déterministes, puis la compare au pourcentage demandé. Il renvoie le hash non signé, la tranche en pourcentage lisible et la décision finale d’inclusion. Aucune valeur aléatoire, horloge, requête réseau ou affectation enregistrée n’influence le résultat : des entrées identiques produisent donc toujours la même sortie.

Choisissez un identifiant représentant le sujet du déploiement

Commencez par un identifiant stable, unique au niveau auquel la fonctionnalité doit être attribuée et disponible partout où la décision est prise. Un ID utilisateur convient à une expérience d’interface individuelle, tandis qu’un ID de compte ou de locataire est généralement préférable lorsque tous les membres d’une organisation doivent observer le même comportement. Les identifiants d’appareil peuvent convenir aux expériences anonymes, mais l’effacement du stockage local risque de modifier l’affectation. Le calculateur considère l’identifiant comme un texte exact : la casse, les espaces, la ponctuation et les caractères Unicode participent tous au hash. Normalisez donc les identifiants avant l’appel si plusieurs systèmes sont susceptibles de les représenter différemment. Décidez, par exemple, si les identifiants ressemblant à des adresses électroniques passent en minuscules, si les ID numériques comportent des zéros initiaux et si une portée telle que production ou préproduction fait partie de la valeur. N’utilisez pas une donnée de profil modifiable, comme le nom affiché. Une fois la convention choisie, conservez-la, car toute modification de l’identifiant change également la tranche.

Comprenez le calcul déterministe de la tranche

La capacité encode l’identifiant en UTF-8 et applique l’algorithme de hash FNV-1a sur 32 bits. Le hash non signé est ramené à l’une des 10,000 tranches en points de base, affichée sous forme d’un nombre compris entre 0 et 99.99. Un sujet est inclus lorsque sa tranche est strictement inférieure au pourcentage demandé multiplié par 100. Cette règle de frontière garantit des extrêmes utiles : zéro pour cent n’inclut personne et cent pour cent inclut tout le monde. Elle permet aussi des évolutions de 0.01 point de pourcentage. Puisque le processus n’emploie ni graine aléatoire, ni temps, ni stockage, ni accès réseau, le même identifiant et le même pourcentage donnent toujours la même réponse. Une hausse du pourcentage conserve tous les sujets déjà inclus et ajoute les identifiants des tranches suivantes ; une baisse retire ceux de la partie supérieure. Ce hash convient à une affectation opérationnelle, mais pas à la sécurité cryptographique. Ne considérez pas sa valeur comme secrète et ne l’utilisez ni pour masquer des identifiants ni pour autoriser un accès.

Intégrez prudemment le résultat à votre processus de livraison

Utilisez le booléen d’inclusion comme l’un des critères de livraison de la fonctionnalité, avec des règles d’éligibilité explicites, des contrôles d’environnement et des dérogations d’urgence. Un service classique exclut d’abord les offres ou régions non prises en charge, puis calcule l’affectation en pourcentage pour le public restant. Enregistrez la configuration du déploiement plutôt qu’une affectation aléatoire distincte par utilisateur, puisque le calcul déterministe peut recréer la décision à tout moment. Avant d’élargir l’exposition, comparez les indicateurs techniques et commerciaux des cohortes éligibles et préparez une désactivation globale rapide. Si plusieurs fonctionnalités indépendantes emploient uniquement le même identifiant, l’ordre de leurs tranches sera corrélé ; ajoutez une clé de fonctionnalité stable, par exemple son nom, un séparateur et l’ID utilisateur, lorsque chaque déploiement nécessite son propre public. Conservez cette clé pendant toute la durée du déploiement. Le point d’accès rejette les pourcentages inférieurs à zéro ou supérieurs à cent au lieu de les borner silencieusement, ce qui rend les erreurs de configuration visibles. Chaque appel coûte $0.002 ; la version navigateur exécute le même calcul pur.