Suivi et conversions

Deux questions différentes se posent à propos d'un lien, et leurs réponses se trouvent à deux endroits différents.

Est-il toujours ouvert ? C'est l'objet lien, et l'API y répond. Fonctionne-t-il ? Ce sont les statistiques, et seul le Dashboard y répond. Savoir distinguer les deux vous évite de chercher des chiffres là où il n'y en a pas.

L'API n'a pas de compteurs

Les vues de la page d'un lien sont comptées, mais rien de tout cela n'atteint l'API. GET /links/{id} renvoie ce que le lien est, jamais ses performances : pas de views, pas de conversions, pas de revenue, ni même de view_count : les nombres de vues ne sont pas exposés dans l'API.

curl https://api.wajub.com/links/8kD2xQpLm \
  -H "Authorization: sk.xxxxxxxxxxxxxxxx…"

La réponse est l'état du lien, et c'est ce que vous interrogez pour savoir s'il encaisse toujours.

La liste fonctionne de la même façon. Elle accepte per_page, search, archived pour voir les liens archivés plutôt que les liens actifs, only_public, type (product, event, fundraising ou donation), et sort_by (created_at, updated_at, title ou type) avec sort_dir (desc ou asc). La liste suit le tri en premier, puis du plus récent au plus ancien entre liens à égalité. Pour les exports, un cursor parcourt la liste dans son ordre par défaut, du plus récent au plus ancien : avec un autre tri, la liste est paginée par numéro et ne porte pas de curseur. Un type, un sort_by ou un sort_dir hors de ces valeurs renvoie une 422 sur ce champ, comme un per_page hors limites.

Ce qui est réellement mesuré

Chaque visite qui passe les verrous d'accès est enregistrée, avec plus de détails que l'objet lien ne le laisse penser.

Les visiteurs uniques sont comptés par jour : la même personne qui visite deux jours différents compte donc pour deux visiteurs uniques. Lisez le nombre de visiteurs uniques comme « uniques par jour », pas comme un nombre de personnes.

Les chiffres, et où les lire

Links → un lien → Analytics est le seul endroit où ils apparaissent. Vous y trouvez les vues et les visiteurs uniques dans le temps, les transactions et le chiffre d'affaires générés par le lien, la transaction moyenne, les principaux pays et types d'appareils, et un export CSV de l'ensemble.

Attribuer un canal

Aucun paramètre d'URL ne marque une visite. Un ?src=whatsapp sur l'URL partagée n'est transmis nulle part : il n'atteint pas le paiement, il n'est pas enregistré sur la vue, et il n'apparaîtra dans aucun rapport.

Vous disposez à la place de deux choses qui fonctionnent.

Le referrer est capturé automatiquement : le trafic qui en porte un, depuis un lien dans une publication ou une page, affiche déjà son origine dans les statistiques. Le trafic venant de WhatsApp, d'un SMS ou d'un QR code n'a pas de referrer, et c'est en pratique l'essentiel du trafic.

Donc, pour tout ce que vous devez vraiment attribuer, créez un lien par canal. Même produit, même prix, custom_url différente : wajub.link/cafe-whatsapp, wajub.link/cafe-instagram. Chacun garde ses propres vues, son propre taux de conversion et son propre chiffre d'affaires, et la comparaison est exacte plutôt que déduite.

Un paiement fait sur un lien le désigne : son champ link est l'id du lien, dans l'API et dans les webhooks payment.*, si bien que votre handler sait de quel lien, donc de quel canal, vient l'argent. GET /payments n'a pas de filtre par lien : pour lister les paiements d'un lien, lisez Links → un lien → Transactions dans le Dashboard, ou gardez le link de chaque paiement à son arrivée.

Comment un lien se ferme

Trois réglages mettent fin à la vie d'un lien, et ils ne le ferment pas de la même façon.

La différence compte. Un lien expiré ou archivé ne s'ouvre jamais : le payeur voit une page fermée et tout s'arrête là. Un lien qui a atteint son plafond de ventes s'ouvre toujours normalement, affiche le produit et le bouton, et ne refuse qu'au moment du paiement. Si vous vendez une quantité fixe, attendez-vous à ce que des payeurs tombent sur ce message plutôt que sur une page fermée.

L'archivage est l'option réversible : remettez is_archived à false via PUT /links/{id} et le lien encaisse de nouveau, en conservant tout ce qu'il a déjà collecté. expiry_date est une condition plutôt qu'un état : la repousser rouvre un lien qui s'était fermé à cause d'elle.

La dépublication avec is_public: false ferme aussi un lien, mais répond 404 au lieu de 410, car un lien non publié doit donner l'impression de n'avoir jamais existé. Les verrous d'accès sont décrits dans Personnalisation.

Le rapprochement des fonds

Les paiements d'un lien sont des paiements ordinaires. Ils arrivent dans votre liste Payments, déclenchent payment.succeeded, sont réglés sur votre solde et se remboursent comme les autres : il n'y a donc rien de propre aux liens à rapprocher.

Le webhook transporte ce que le payeur a saisi dans vos extra_fields, imbriqué sous metadata.extra_fields. Si vous devez savoir depuis votre propre code quel lien a produit un paiement, aujourd'hui cela veut dire le demander au payeur, via un champ, ou séparer par lien comme ci-dessus.