Règles de ciblage

Temps de lecture : 5 minutes. Pour qui : les marchands qui veulent restreindre qui voit le bouton de devis et qui peut envoyer une demande.

QuotWay sépare le ciblage côté produit (« sur quels produits le bouton de devis s'affiche-t-il ? ») du ciblage côté client (« quels acheteurs peuvent envoyer une demande ? »). Les deux fonctionnent comme une chaîne de règles : chaque règle autorise ou refuse, et la première règle correspondante l'emporte.

Les deux portées

Portée	Question posée	Par défaut, sans règle
PRODUCTS	« Le bouton de devis doit-il s'afficher sur ce produit ? »	Refus - bouton masqué.
CUSTOMERS	« Cet acheteur a-t-il le droit d'envoyer une demande ? »	Refus - demande rejetée.

Le refus par défaut est délibéré. Sans aucune règle, aucun acheteur ne voit le bouton. La configuration initiale crée pour vous une règle de base ALL_PRODUCTS + ALL_CUSTOMERS : vous démarrez donc avec le bouton visible par tout le monde.

Types de règles

Côté produit

ALL_PRODUCTS - tous les produits affichent le bouton.
COLLECTION - n'afficher que sur les produits d'une collection donnée.
PRODUCT_TAG - n'afficher que sur les produits portant un tag donné (par exemple wholesale). Accepte ANY (au moins un tag) ou ALL (tous les tags).
PRODUCT_TYPE - correspondance par type de produit Shopify.
VENDOR - correspondance par fournisseur de produit Shopify.

Côté client

ALL_CUSTOMERS - tous les acheteurs peuvent envoyer une demande.
CUSTOMER_TAG - correspondance par tag client Shopify (par exemple vip). ANY ou ALL.
CUSTOMER_SEGMENT - correspondance par segment de clientèle Shopify. L'appartenance est résolue côté serveur auprès de Shopify : un segment reste donc la source de vérité, plutôt que de faire confiance à ce que transmet la boutique.
B2B_COMPANY - sur les boutiques compatibles B2B (Professional et au-delà). Correspondance par GID d'entreprise.
COMPANY_LOCATION - sur les boutiques compatibles B2B (Professional et au-delà). Correspondance par site d'entreprise.
GUEST - autoriser explicitement les acheteurs non connectés.

Ordre des règles et priorité

Chaque règle porte une priority (plus la valeur est basse, plus la priorité est haute). Quand QuotWay évalue s'il doit afficher le bouton :

Il trie les règles par priority croissante.
Il parcourt la liste. La première règle dont les conditions correspondent au couple produit + acheteur l'emporte.
Si aucune règle ne correspond, c'est un refus.

Une règle peut être activée (en vigueur) ou désactivée (conservée pour plus tard mais ignorée). L'éditeur de ciblage, à l'adresse /app/quote-button/targeting, propose un interrupteur pour chacun de ces états.

Modifier les règles

L'éditeur dédié, à l'adresse /app/quote-button/targeting, affiche toutes les règles des deux portées. Chaque ligne comporte :

un nom et un badge de portée (PRODUCTS / CUSTOMERS) ;
le type de règle ;
les conditions (par exemple tags: ["wholesale"], operator: ANY) ;
l'interrupteur d'activation ;
la priorité.

Cliquez sur une règle pour ouvrir l'éditeur de conditions.

Exemple concret - produits marqués « wholesale », clients marqués B2B

Imaginons que vous vendiez à des grossistes via des produits spécialement marqués, et que vos acheteurs de confiance portent un tag client wholesale-customer. Vous voulez que le bouton de devis n'apparaisse QUE si les deux correspondent.

Règles :

#	Portée	Type	Conditions	Priorité	Activée
1	PRODUCTS	PRODUCT_TAG	`tags: ["wholesale"], operator: ANY`	100	✓
2	CUSTOMERS	CUSTOMER_TAG	`tags: ["wholesale-customer"], operator: ANY`	100	✓

C'est tout : deux règles. Le bouton s'affiche quand le produit porte le tag wholesale ET que l'acheteur porte le tag wholesale-customer.

Exemple concret - acheteurs non connectés et produits marqués

Si vous voulez que même les acheteurs non connectés puissent envoyer des demandes (courant pour un premier contact B2B) :

#	Portée	Type	Conditions	Priorité	Activée
1	PRODUCTS	PRODUCT_TAG	`tags: ["wholesale"], operator: ANY`	100	✓
2	CUSTOMERS	GUEST	(aucune)	100	✓
3	CUSTOMERS	ALL_CUSTOMERS	(aucune)	200	✓

La règle 2 autorise explicitement les visiteurs sans compte ; la règle 3 attrape les clients connectés.

L'application est côté serveur, pas seulement à l'affichage

La visibilité du bouton n'est que la couche d'affichage. Ce n'est pas elle qui empêche un produit non éligible d'être chiffré.

Quand un devis est envoyé, QuotWay réexécute la même évaluation de règles sur le serveur à partir de vos règles enregistrées, et rejette la demande si une ligne n'est pas éligible. Deux détails rendent ce contrôle fiable :

Les attributs produit transmis par le client sont remplacés, pas crus sur parole. La requête venue de la boutique porte, pour chaque ligne, le type de produit, le fournisseur, les tags et les collections - autant de valeurs qu'une requête forgée pourrait inventer. Avant l'évaluation, le serveur les écarte et les remplace par les valeurs de référence récupérées via l'Admin API. Il en va de même pour les tags client, eux aussi récupérés à nouveau plutôt que repris de la requête.
Tout échec vaut refus. Si un produit ne peut pas être résolu - ou si la récupération auprès de l'Admin API échoue entièrement - la ligne est traitée comme non éligible plutôt que laissée passer.

Les demandes issues du panier sont filtrées avant même l'ouverture du tiroir : seules les lignes éligibles sont reprises dans le devis, et les articles non éligibles sont écartés plutôt que chiffrés en silence.

Deux points à connaître sur la portée. L'éligibilité est évaluée au moment où l'acheteur envoie sa demande : un produit exclu plus tard ne ferme donc pas rétroactivement les devis déjà existants. Et un devis que vous créez dans l'interface d'administration n'est pas soumis au contrôle d'éligibilité : vous choisissez les produits explicitement, les règles qui protègent votre boutique ne s'appliquent donc pas à vous.

Cela compte si vos exclusions existent pour une raison opérationnelle - des réparations ou des échanges qui suivent un autre circuit, par exemple - car cela signifie qu'un produit exclu ne peut pas vous parvenir par la boutique, quelle que soit la forme de la demande.

Performance et mise en cache

Les règles de ciblage sont lues à chaque chargement de page de la boutique. Pour garder une latence basse, QuotWay met la liste des règles en cache par boutique pendant 5 minutes.

Quand vous créez, modifiez ou supprimez une règle, le cache est invalidé immédiatement pour cette boutique.
Le cache est en mémoire, par instance de fonction Vercel : le trafic monte donc linéairement sans requête en base par boutique.

Vous ne devriez PAS voir de règles périmées en usage normal. Si cela arrive, la procédure de diagnostic se trouve dans Problèmes courants.

Pièges courants

Le bouton ne s'affiche pas alors que mon produit porte le tag. La correspondance des tags est sensible à la casse (« wholesale » ≠ « Wholesale »). Le catalogue Shopify comporte parfois une casse incohérente sur d'anciens tags - choisissez une casse et tenez-vous-y.
Une règle PRODUCT_TAG avec operator: ALL et 2 tags fonctionne sur certains produits mais pas d'autres. Vérifiez que chaque produit porte bien les DEUX tags. L'opérateur exige une correspondance exacte sur tous.
Une règle d'entreprise B2B ne correspond pas. Utilisez le GID de l'entreprise (gid://shopify/Company/12345), pas son nom. L'autocomplétion de l'éditeur évite ce piège, mais si vous collez un nom venu d'ailleurs, la règle échoue silencieusement.
Des règles d'un ancien forfait apparaissent encore. Désactiver une règle la conserve. Utilisez l'action Supprimer pour l'effacer.