Markin + SDK web et mobile integration
Décisions en session rendues dans tes propres surfaces.
Qu'est-ce qu'une SDK web et mobile Agent IA ?
Le SDK web et mobile Markin demande une décision au moment du rendu et reçoit une action plus sa raison, avec un fallback défini et un budget de latency. C'est ainsi que les surfaces en session telles que les paywalls, les écrans d'accueil et le paiement obtiennent une décision sans aller-retour via un canal.
Certaines surfaces ne peuvent pas attendre un intervalle de synchronisation. Un paywall ou un emplacement sur l'écran d'accueil demande une réponse au moment du rendu et en obtient une, et la surface se rend toujours même si Markin ne répond pas.
Ce que Markin lit
- Contexte de Session transmis au moment de la requête
Ce que Markin renvoie
- Une action plus sa raison, par requête, avec une valeur par défaut de repli
Comment la connexion fonctionne
| Pattern | Ce que cela signifie ici |
|---|---|
| API de Décision | La surface demande à Markin une décision au moment du rendu et reçoit une action plus sa raison, avec un mécanisme de secours défini. |
| Surface directe | Markin insère directement un emplacement dans le produit ou le corps du message, pour les placements où un aller-retour via un canal n'ajoute rien. |
Que peux-tu demander à Markin de faire dans SDK web et mobile?
- Comment personnaliser un paywall en temps réel ?
- Comment puis-je ajouter une API de décision à mon application sans la ralentir ?
- Qu'est-ce qui s'affiche si le service de décision est indisponible ?
- Comment tester les offres in-product contre un holdout ?
Ce que Markin fait en SDK web et mobile
- 01Sers une décision par requête de surface dans la limite du budget de latence.
- 02Retourne la raison avec l'action pour la journalisation et l'audit.
- 03Prévois un mécanisme de repli vers une valeur par défaut définie lorsqu'aucune décision n'est disponible.
- 04Mets en cache les décisions par session pour éviter les appels répétés.
- 05Assigne et respecte l'appartenance au holdout au niveau de l'appareil.
- 06Émets automatiquement des événements d'impression et d'interaction.
- 07Respecte l'état du consentement transmis par le client.
- 08Rapporte les revenus incrémentaux par surface et par slot.
Étendue des travaux
Le travail de growth derrière SDK web et mobile
La liste ci-dessus est ce que Markin couvre en SDK web et mobile. Un connecteur n'est que la surface. En dessous se trouve le travail lui-même : ce qu'un analyste, un lifecycle manager, un data scientist et un responsable de l'expérimentation feraient entre eux, fonctionnant en continu sur tes propres données.
Lis le patrimoine
Normalement un ingénieur de données, une fois, puis jamais actualisé.
- Lis l'historique des contacts afin que les envois passés comptent comme une pression sur le client.
- Suis les changements de catalogue, de prix et de plan au fur et à mesure qu'ils se produisent.
Trouve où les revenus s'échappent
Normalement une analyse approfondie trimestrielle par un analyste.
- Repère les incohérences de prix et de packaging entre ce que les gens achètent et ce qu'ils utilisent.
- Repère la friction produit qui est corrélée à la dégradation et à l'annulation.
Explique pourquoi
Normalement une investigation de deux semaines retirée de la roadmap.
- Sépare les effets de mix des changements de comportement réels.
- Classe les facteurs par leur contribution au mouvement.
Écris des hypothèses qui méritent d'être financées
Normalement un atelier, limité aux idées présentes dans la pièce.
- Joins les preuves et l'hypothèse dont chacune dépend.
- Classe le portefeuille par valeur attendue, et non par ancienneté.
Décider par client
Normalement les règles de segmentation sont rafraîchies quand quelqu'un a le temps.
- Arbitrer entre chaque action en concurrence pour ce même client.
- Applique les plafonds de fréquence, la fatigue et les heures calmes avant que quoi que ce soit ne soit engagé.
Exécute dans les outils que tu utilises déjà
Normalement un ticket, puis un créneau dans le calendrier du mois suivant.
- Écris les décisions dans les systèmes CRM, d'engagement et d'entrepôt de données déjà en production.
- Déclenche des parcours et des campagnes que ton équipe lifecycle possède et peut modifier.
Prouver que cela a généré du chiffre d'affaires
Normalement discuté, rarement mesuré.
- Lis l'uplift de revenus par client par rapport à ce groupe de contrôle.
- Rapporte la retention, l'ARPU, la marge et la pression de contact côte à côte.
Retire, gouverne et transfère.
Normalement le travail de personne, donc rien n'est jamais désactivé.
- Retire automatiquement les programmes lorsqu'ils ne battent plus le contrôle.
- Re-tester les hypothèses qui se dégradent, telles que la sensibilité aux prix et la saisonnalité.
Les équipes utilisent SDK web et mobile avec
SDK web et mobile questions
- How does Markin connect to Web and mobile SDK?
- Decision API, Direct surface. The surface asks Markin for a decision at render time and receives one action plus its reason, with a defined fallback.
- What does Markin read from Web and mobile SDK?
- Session context passed at request time.
- What does Markin write back into Web and mobile SDK?
- Une action plus sa raison, par requête, avec une valeur par défaut de repli
- Devons-nous déplacer nos données vers Markin ?
- Non. Markin lit depuis ton entrepôt de données, tes événements produits et tes systèmes opérationnels en place, sur tes ressources de calcul, sous les règles d'accès que ton équipe de données a déjà définies. Rien n'est copié dans une base clients séparée et il n'y a pas de magasin de profils côté fournisseur à migrer ultérieurement.
- Markin remplace-t-il notre plateforme d'engagement ou notre CDP ?
- Non, et cela ne devrait pas l'être. Ta plateforme d'engagement conserve le canal, les modèles, la délivrabilité et la gouvernance. Ton CDP conserve l'identité et le consentement. Markin ajoute la couche qu'aucune n'a : décider quelle action mérite d'exister pour chaque client, et le prouver contre un holdout.
- Et si le système que nous utilisons n'est pas répertorié ?
- Les quatre modèles d'activation couvrent presque tout : l'écriture d'attributs, l'événement déclenché, l'API de décision et le rendu de surface direct. Tout système qui expose une API, accepte un tableau, ou peut lire une colonne d'entrepôt peut recevoir des décisions. Les nouveaux connecteurs sont construits pendant le déploiement, généralement en quelques jours.