Peut-on préparer des tags avant de connaître le contenu ?
Oui, et c'est l'habitude de production la plus utile qui soit. Écrivez maintenant une adresse unique sur votre propre domaine sur chaque tag, posez-les, et décidez plus tard vers quoi chacun redirige. Les tags sont finis avant que le contenu n'existe.
Le schéma
Au lieu d'écrire la destination finale sur chaque tag, écrivez une adresse sur un domaine que vous contrôlez, avec un identifiant qui distingue un tag d'un autre. Votre serveur décide où mène cet identifiant.
Le tag est alors définitif et la destination ne l'est pas. Encodage, impression et pose peuvent tous se faire avant que quiconque n'ait décidé de ce que dira la campagne, et changer la destination plus tard est une modification en base de données plutôt qu'une visite sur site.
Pourquoi cela change la production
Trois contraintes disparaissent d'un coup, et ce sont les trois qui rendent les projets de tags pénibles.
Le contenu ne bloque plus la production. Les tags peuvent être écrits et posés pendant que la destination se discute encore, ce qui supprime la dépendance qui retarde d'ordinaire tout le reste.
Les erreurs cessent d'être définitives. Une mauvaise destination sur mille tags posés est une correction au serveur plutôt que mille remplacements.
Et les tags peuvent être verrouillés sans risque. Verrouiller un tag qui porte une adresse de redirection est une vraie option, puisque l'adresse n'aura jamais à changer, ce qui n'est pas vrai d'un tag qui porte directement la destination.
C'est ce qui rend le verrouillage sensé
Le verrouillage est d'ordinaire une mauvaise idée parce que le contenu change. Verrouiller un tag dont le contenu est un pointeur stable lève cette objection, et vous donne une résistance à la falsification sans rien coûter en souplesse.
Ce qu'il faut mettre en place
Un domaine que vous contrôlez, un moyen d'associer un identifiant à une destination, et un relevé de quel tag porte quel identifiant.
Ce dernier point est celui qu'on saute et qu'on regrette. Si personne ne sait quel tag porte quel identifiant, vous pouvez changer les destinations sans savoir quel objet physique vous changez, ce qui perd l'essentiel du bénéfice.
Gardez les identifiants courts. Chaque caractère est un octet sur le tag, et un identifiant court est aussi plus facile à porter sur une étiquette pendant l'assemblage.
Là où cela ne s'applique pas
Partout où le tag doit fonctionner sans réseau. Une redirection est un lien, et un lien demande de la couverture : ce schéma est donc indisponible pour les tags censés fonctionner hors ligne.
Pour des coordonnées remises dans une mauvaise couverture, pour des tags d'équipement en sous-sol, pour tout ce dont le fonctionnement hors ligne est l'objet, le contenu doit être sur le tag et la souplesse est perdue. C'est un arbitrage réel plutôt qu'un oubli.
Cela crée aussi une dépendance à votre propre infrastructure. Si le domaine tombe, tous les tags déployés sous lui cessent de fonctionner en même temps, ce qui est un mode de défaillance qui mérite d'être prévu plutôt que découvert.
Questions fréquentes
Cela fonctionne-t-il avec un service de raccourcissement d'adresses ?
Cela fonctionne et cela crée une dépendance à une société que vous ne maîtrisez pas. Si ce service ferme ou change ses conditions, tous les tags s'arrêtent. Votre propre domaine supprime le risque pour un coût dérisoire.
Peut-on changer la destination d'un seul tag ?
C'est tout l'objet, à condition que chaque tag porte son propre identifiant. Des tags qui partagent une adresse ne peuvent être changés qu'ensemble.
Une redirection est-elle plus lente pour l'utilisateur ?
Elle ajoute un saut, imperceptible sur toute connexion normale. Le gain de fiabilité vaut bien plus que les millisecondes.
Et si je n'ai pas de site web ?
Un domaine et un service de redirection coûtent peu et ne demandent aucun site. Ce qui compte est de posséder le domaine, non d'y construire quoi que ce soit.