Identité d’appareil et facturation

FortressFlag facture par appareil, pas par app : le modèle veut qu’un téléphone qui exécute trois de vos apps soit un siège, pas trois. Cette page explique l’identité qui rend cela possible, ce que cela signifie pour votre facture, et les faits de plateforme — y compris là où la promesse d’un seul siège demande une configuration, et là où elle ne tient pas encore — que vous voudrez connaître avant qu’ils n’apparaissent dans un chiffre.

Un siège est un appareil actif mensuel

Votre utilisation pour un mois est le nombre d’appareils distincts qui ont demandé des flags pendant ce mois calendaire (UTC), sur l’ensemble de vos environnements et de vos apps. Un appareil qui interroge une fois compte une fois ; un appareil qui interroge dix mille fois compte une fois. Un polling efficace ne gonfle pas votre facture, et les mois calmes coûtent moins.

L’identité est créée, pas dérivée

La première fois que l’une de vos apps démarre le SDK sur un appareil, le SDK crée un identifiant aléatoire — dev_ suivi de 22 caractères — et le stocke sur l’appareil. C’est toute l’identité :

• Aléatoire, jamais dérivée. Ce n’est pas l’identifiant publicitaire, pas un numéro de série matériel, pas un hachage de quoi que ce soit concernant votre utilisateur. Elle ne peut pas être remontée jusqu’à une personne, et elle ne relie pas l’activité entre les apps de différents éditeurs. Au sens du RGPD, c’est un identifiant pseudonyme — nous le traitons comme une donnée personnelle, et il est conçu pour porter aussi peu qu’un identifiant peut porter.
• Stable par appareil. Sur iOS, vos apps peuvent partager une seule identité via un groupe d’accès au trousseau partagé, de sorte que trois de vos apps sur un iPhone comptent pour un appareil — la promesse par appareil, tenue par construction. Sur Android, l’identité est par app aujourd’hui : chacune de vos apps crée la sienne, et compte séparément.
• Réinitialisable. Chaque SDK expose une réinitialisation qui supprime et recrée l’identité — le chemin d’effacement de l’identifiant. La conséquence, dite honnêtement : après une réinitialisation, l’appareil compte comme un nouvel appareil.

Les simulateurs sont servis, jamais facturés

Les builds qui tournent dans un simulateur ou un émulateur créent une identité sim_ à la place. FortressFlag leur sert des flags exactement comme aux vrais appareils et les exclut entièrement du comptage — les simulateurs de votre équipe, votre CI et vos tests de navigateur automatisés ne vous coûtent jamais un siège. (Sur le web, un navigateur automatisé qui s’annonce via navigator.webdriver reçoit une identité sim_ — vos suites Playwright et Cypress sont couvertes.)

Votre écran Utilisation montre le ratio quotidien entre trafic réel et trafic de simulateur, de sorte qu’un build mal configuré qui facture des simulateurs comme des appareils — ou qui cache des appareils en simulateurs — est visible, pas silencieux.

Les faits de plateforme, dits simplement

Chaque plateforme stocke l’identité aussi durablement que la plateforme le permet, et aucune plateforme ne permet « pour toujours ». Voici les conséquences que vous observerez réellement :

• iOS : l’identité vit dans le trousseau et survit aux désinstallations de l’app. Elle n’est jamais synchronisée avec iCloud — une identité qui voyagerait dans une sauvegarde vers un second iPhone facturerait un appareil comme deux.
• Android : l’identité est effacée quand votre app est désinstallée — une réinstallation crée une nouvelle identité, qui est un nouvel appareil facturable. Un fait de plateforme, intégré au prix.
• Web : l’identité vit dans le stockage du navigateur, limité à l’origine. Une fenêtre privée/de navigation privée crée une identité jetable qui compte comme un appareil pour cette session, et un utilisateur qui efface les données du site est un nouvel appareil. De plus : une même personne qui utilise votre site web, votre app iOS et votre app Android représente jusqu’à trois appareils — un par plateforme. Il n’y a aucun lien entre plateformes, par conception.

L’essai, et ce qui se passe à sa limite

Chaque essai inclut 1 000 appareils actifs mensuels, et les essais n’expirent jamais avec le temps — vous pouvez évaluer aussi longtemps que nécessaire. Si le nombre d’appareils d’un mois dépasse le palier, l’application de la limite arrive par étapes, jamais comme une falaise :

1. Tout de suite : une bannière dans le tableau de bord pour tout le monde dans votre équipe.
2. Après 14 jours de dépassement : le tableau de bord passe en lecture seule — les flags continuent d’être servis, vous ne pouvez simplement plus rien changer jusqu’à ce que vous achetiez ou que l’utilisation redescende.
3. Après 28 jours de dépassement : les appareils au-delà des 1 000 premiers reçoivent les valeurs par défaut des flags. Les 1 000 premiers appareils gardent les vraies valeurs tout du long — vos premiers utilisateurs ne sont jamais ceux qui sont dégradés.

Acheter la formule payante efface tout cela instantanément.

Ce que nous conservons, et pendant combien de temps

Le comptage doit dénombrer des appareils distincts, donc les identifiants bruts d’appareil sont conservés pendant 13 mois — de quoi couvrir un an d’historique d’utilisation plus le mois en cours — puis supprimés. Votre écran Utilisation montre la période en cours et 12 mois d’historique. Ce qui transite vers notre prestataire de paiement, ce sont des nombres d’appareils, jamais des identifiants d’appareil.

Où aller ensuite

• Comment les flags arrivent à votre app — la requête qui porte l’identité
• Lisez votre utilisation et votre facturation — l’écran Utilisation de l’Owner
• Clés — ce qui authentifie la requête de l’appareil