Comment nous avons construit le parrainage de Notis avec Rewardful

Un programme de parrainage devient un problème produit dès que quelqu’un demande : « Il est où, mon lien ? »

Tu peux présenter l’offre à merveille et la rendre quand même pénible à utiliser. La personne a besoin de son lien, d’un moyen de le partager, d’un moyen de voir ce qui s’est passé, et de l’assurance que le compte de l’autre côté est bien le sien.

Chez Notis, nous utilisons Rewardful pour les liens d’affiliation, les codes promo, les commissions et l’accès au tableau de bord partenaire. Nous avons intégré la connexion de compte et l’expérience de parrainage dans notre propre produit. Voici comment se répartissent les responsabilités, et ce à quoi je ferais attention si je devais le reconstruire.

Pas de tour d’honneur sur les revenus d’affiliation ici. Ce qui est utile, c’est l’implémentation : rendre le programme accessible là où les clients gèrent déjà leur compte, tout en laissant au système d’affiliation la maîtrise claire des données d’affiliation.

Placer le parrainage près du compte

Notis est un assistant IA qui fonctionne par messages, à la voix, via une app Desktop et web, et à travers des outils connectés. Les paramètres du compte rassemblent déjà ce dont une personne a besoin pour gérer sa relation avec le produit.

C’est un endroit logique pour un lien et un code de parrainage personnels. L’utilisateur ne devrait pas avoir à retrouver un e-mail d’onboarding pour les dénicher. Notre version d’août a lancé publiquement cette expérience, avec l’accès à un tableau de bord partenaire.

Derrière l’interface, nous devons relier un compte Notis au bon affilié Rewardful. Ça ressemble à une simple recherche. Ça devient plus intéressant quand les gens ont des alias e-mail, des comptes d’affilié existants, ou plusieurs requêtes qui arrivent en même temps.

Ma première leçon d’implémentation : commence par l’identité, avant de te soucier de la couleur du bouton pour copier le lien.

Décider quel système détient quelles données

Rewardful est notre source de vérité pour les informations d’affiliation. Notis stocke la correspondance durable nécessaire pour retrouver le bon affilié et afficher le lien et le code personnels concernés.

Cette distinction nous évite de construire par accident une seconde plateforme d’affiliation dans notre propre base de données. Nous n’avons pas besoin de détenir le registre des commissions pour proposer un écran de parrainage utile. Nous avons en revanche besoin de savoir quelle fiche distante appartient à la personne qui ouvre cet écran.

L’API de création d’affiliés de Rewardful permet de créer des affiliés au sein du workflow d’une application. Dans notre implémentation, c’est le backend qui s’en charge, en gardant les identifiants du fournisseur hors du navigateur.

La question de conception que je poserais à un autre fondateur : si ces deux systèmes ne sont pas d’accord demain, lequel l’emporte ? Écris-le pour chaque type de données. Un vague « on les synchronise » est une invitation à des cas limites déroutants plus tard.

Retrouver les personnes existantes avant de créer de nouvelles fiches

Notre flux de correspondance cherche d’abord les affiliés existants à partir de l’e-mail principal, puis examine un alias vérifié unique. Les correspondances ambiguës sont mises de côté pour examen plutôt que tranchées au hasard.

C’est important, parce que l’identité d’un affilié est liée à l’argent et à la réputation de quelqu’un. Une correspondance pratique n’est pas forcément la bonne. Renommer ou fusionner la fiche d’un partenaire existant pour qu’un parcours d’onboarding ait l’air propre serait un mauvais calcul.

Pour les nouveaux affiliés, notre implémentation coordonne aussi les créations simultanées. L’inscription et la page de parrainage peuvent toutes deux chercher à s’assurer qu’un affilié existe. Un verrou partagé empêche ces workers de décider chacun de leur côté de créer une nouvelle fiche pour le même compte.

Pas besoin de notre mécanisme exact pour tirer la leçon. Demande-toi ce qui se passe quand une requête est répétée, quand le navigateur se rafraîchit, et quand deux workers tournent en même temps. Si chaque nouvelle tentative peut créer une nouvelle personne, l’intégration mérite plus de réflexion.

Un lien et un code règlent des problèmes de partage différents

Un lien personnel est pratique quand quelqu’un peut cliquer dessus. Un code promo est utile quand une recommandation circule dans une conversation, une capture d’écran ou tout autre endroit où le lien d’origine s’est perdu.

Notre Portal affiche les deux quand la correspondance d’affilié et le code sont disponibles. Le code est rattaché à l’affilié, au lieu d’être une réduction générique qui perdrait la relation que nous cherchons justement à préserver.

Rewardful documente le suivi par code promo comme un moyen de gérer les parrainages quand l’attribution par lien n’est pas pratique. Dans Notis, les liens et les codes saisis à la main arrivent au paiement par des chemins différents, donc leur validation et leur traitement côté fournisseur ne doivent pas être présentés comme identiques.

C’est la leçon produit utile : donne aux gens plusieurs façons de partager, puis comprends comment chacune est créditée. N’ajoute pas un second champ dans l’interface en supposant que la logique backend est automatiquement la même.

Vérifier le parrainage avant de promettre l’avantage

Dans notre parcours de paiement explicite par lien de parrainage, le backend vérifie le parrainage à distance, contrôle l’éligibilité, rejette l’auto-parrainage et n’applique la réduction configurée que si les conditions requises sont remplies.

Si la vérification est temporairement indisponible, ce parcours renvoie une erreur qu’on peut réessayer, au lieu de continuer discrètement à un autre prix. Le principe est simple : une fois que l’expérience a promis un avantage de parrainage, une panne d’intégration invisible ne doit pas changer en silence les conditions au moment du paiement.

Les appels au fournisseur ont aussi besoin d’une gestion partagée des limites de débit. Un rattrapage de données et une requête client interactive peuvent solliciter le même compte fournisseur. Nous coordonnons les requêtes entre workers pour que les créations en arrière-plan n’ignorent pas les contraintes que le reste de l’application doit respecter.

Ce sont des choix d’implémentation, pas la preuve d’une baisse mesurée des tickets de support ou de la fraude. Je peux expliquer pourquoi nous les avons faits sans prétendre avoir prouvé chaque résultat espéré.

L’accès au tableau de bord doit suivre l’état actuel du compte

Nous utilisons l’authentification unique de Rewardful pour donner accès au tableau de bord partenaire depuis Notis. L’URL est générée au moment où on en a besoin, au lieu d’être traitée comme un lien permanent à stocker et à faire circuler.

Nous rafraîchissons aussi l’état de l’affilié pour les lectures dans le Portal et l’accès au tableau de bord. Une correspondance autrefois valide ne doit pas devenir une faille qui continue de fonctionner après un changement de la fiche chez le fournisseur.

Pour l’utilisateur, l’expérience voulue est simple : ouvrir le parrainage, trouver ses informations personnelles et accéder au tableau de bord. Les contrôles se font derrière cette interaction. Un bon travail d’intégration consiste souvent à gérer la coordination pénible pour que la tâche visible reste légère.

Construire les parcours ordinaires et les parcours tordus

Si je devais cadrer une intégration de parrainage de zéro, je testerais un affilié existant, un nouvel affilié, une requête répétée, une identité ambiguë, un code manquant et un fournisseur temporairement indisponible. J’examinerais aussi séparément le parcours par lien et le parcours par code.

C’est ainsi que je vois Rewardful dans Notis. Rewardful détient la mécanique d’affiliation ; nous la relions avec soin au produit que les gens utilisent déjà. Commence par rendre le bon lien disponible de façon fiable pour la bonne personne. Le récit de croissance peut attendre que tu aies des résultats qui méritent d’être partagés.