Le but de ce guide est de te donner l’architecture complète, utilisée par les meilleurs SaaS (Notion, Stripe, Figma, Monday, HubSpot), décomposée étape par étape.

1. Introduction — Pourquoi une architecture tracking SaaS complète est indispensable
Un SaaS moderne doit mesurer en continu :

• le marketing (acquisition, attribution),

• le produit (activation, feature usage),

• le business (paiements, renouvellements, MRR, churn),

• la rétention (DAU/WAU/MAU),

• le support & le succès client (onboarding calls, tickets),

• la performance mobile + web,

• le multi-device,

• les interactions offline,

• les automatisations backend.

Bref : un SaaS vit partout, tout le temps.

Et sans une architecture tracking solide, tu obtiens :

❌ KPIs contradictoires
❌ attribution éclatée
❌ fondues web/app non connectées
❌ churn non expliqué
❌ LTV sous-estimée
❌ mauvaise compréhension de l’activation
❌ décisions business basées sur des données imprécises

Le but de ce guide est de te donner l’architecture complète, utilisée par les meilleurs SaaS (Notion, Stripe, Figma, Monday, HubSpot), décomposée étape par étape, pour :

• obtenir une Customer 360 complète,

• analyser l’activation, la rétention, l’expansion, le churn,

• améliorer drastiquement ton produit,

• optimiser ton marketing,

• piloter ton MRR avec précision,

• unifier web + mobile + backend + CRM + offline.

Prépare-toi : on construit une archi solide, moderne, durable.

2. Les briques d’une architecture tracking SaaS moderne

Avant d’assembler, il faut comprendre les briques.

2.1. Le tracking web (JS)

Collecte :

• pages vues,

• events produit,

• funnels,

• interactions UI.

Limites :

• cookies faibles (ITP Safari, Firefox)

• adblockers

• données peu fiables comparées au backend

Usage recommandé : comportement utilisateur + événements non critiques.

2.2. Le tracking mobile (SDK iOS/Android)

Collecte :

• écran, feature usage, app_open

• notifications push

• signup/login mobile

• achats in-app

• deferred deep links

Forces :

• très fiable

• très peu bloqué

• User-ID stable

Usage : rétention, activation mobile, usage produit.

2.3. Le tracking backend / server-side (SOURCE DE VÉRITÉ)

C’est la brique la plus importante d’un SaaS.

Elle collecte :

• création de comptes, workspaces, organisations

• abonnements Stripe / Chargebee

• upgrades / downgrades

• churn

• trial start / trial end

• quotas dépassés

• imports / exports

• automatisations internes

• API calls

Le backend représente la vérité business.

2.4. Le tracking offline (CRM, sales, support)

Dans un SaaS, le parcours client inclut souvent :

• un appel de qualification,

• une demo,

• un onboarding call,

• des tickets support,

• des interactions manuelles (upgrade manuelle, churn administratif).

Ne pas les tracker = perdre 40% du funnel réel.

2.5. Le data warehouse (BigQuery / Snowflake)

La brique la plus critique pour les entreprises matures.

Le warehouse permet :

• fusion web/mobile/backend

• modélisation Customer 360

• cohorte d’activation, de rétention, de LTV

• attribution marketing complète

• analyses produit avancées

• détection prédictive (churn, expansion)

C’est le point de vérité ultime.

3. Étape 1 — Définir les objectifs business du tracking

Un tracking ne se construit pas en listant des événements au hasard.
Il se construit en répondant à 3 questions :

3.1. Acquisition : quelles questions doit-on éclairer ?

• Quels canaux génèrent de vrais utilisateurs activés ?

• Quelle source amène des clients payants (pas seulement des signups) ?

• Quel canal génère la meilleure LTV ?

• Combien coûte un utilisateur activé ?

3.2. Activation : comment identifier le “Aha moment” ?

Un SaaS n’a pas 1 activation → il en a 3 :

• activation technique (signup → onboarding complet),

• activation produit (“Aha moment”),

• activation revenue (le moment où l’utilisateur paye).

Ton tracking doit révéler :

→ quelles actions mènent à l’activation
→ quelles actions prédisent le churn
→ quelles améliorations réduisent l’activation time

3.3. Rétention & expansion

• Quelles fonctionnalités prédisent la rétention à 7/30/90 jours ?

• Quel usage produit prédit l’upsell ?

• Quelles actions précèdent un downgrade ou churn ?

Le tracking doit mesurer tout ce qui influence la valeur client.

4. Étape 2 — Construire un plan de tracking SaaS (event architecture)

Voici la base d’un vrai plan de tracking SaaS moderne.

4.1. Nommage des événements — règles d’or

Format obligatoire :
👉 verbe + objet
En anglais (standard universel, LLM-friendly).

Exemples :

• account_created

• workspace_created

• project_created

• feature_used

• payment_failed

• subscription_upgraded

À éviter :
❌ ProjectCreation
❌ utilisateurCree
❌ create_project_event_v2

Les LLM ne les comprennent pas bien.
Les PMs non plus.

4.2. Structure des propriétés

Chaque événement doit contenir :

Toujours en snake_case.

4.3. Les 5 familles d’événements SaaS

1. Onboarding

• signup_started

• signup_completed

• onboarding_step_completed

• onboarding_completed

2. Feature usage

• feature_used

• project_created

• file_uploaded

• integration_connected

3. Collaboration (SaaS multi-user)

• team_invited

• role_updated

• workspace_joined

4. Billing (backend)

• subscription_started

• payment_succeeded

• payment_failed

• subscription_cancelled

• subscription_renewed

5. Off-line / CRM

• demo_booked

• onboarding_call

• ticket_resolved

• manual_upgrade

4.4. Exemple JSON d’un événement complet

{
  "event": "project_created",
  "user_id": "u_4910",
  "workspace_id": "w_220",
  "properties": {
    "device": "web",
    "source": "google_ads",
    "plan_type": "pro",
    "feature_name": "projects",
    "project_type": "design"
  },
  "timestamp": "2025-02-10T15:21:35Z"
}

5. Étape 3 — Implémenter le tracking web

5.1. Choisir l’approche web (2 stratégies)

A — SDK direct (Segment.js, Mixpanel.js, Amplitude.js)

✔️ fiable
✔️ stable
❌ moins flexible pour les équipes marketing

B — Tag Manager (GTM)

✔️ flexible
✔️ rapide à déployer
❌ moins fiable (adblockers)

Recommandation : modèle hybride

SDK → events critiques
GTM → marketing / opportunistes

5.2. Envoyer le User-ID côté web

Le user_id doit venir du backend (après login/signup).

window.user_id = "{{USER_ID_FROM_BACKEND}}";

analytics.identify(window.user_id);

En GTM :

dataLayer.push({
  user_id: window.user_id
});

5.3. Événements web critiques à implémenter

• signup_started

• signup_completed

• login

• onboarding_step_completed

• feature_used

• checkout_started

• checkout_completed

Ces événements alimentent activation + conversion.

6. Étape 4 — Implémenter le tracking mobile (iOS + Android)

6.1. Installer un SDK mobile

Exemple avec Segment :

analytics.identify(userId);
analytics.track("feature_used", { feature_name: "projects" });

6.2. Harmoniser le tracking web ↔ mobile

Le même événement = même nom :

Aucune exception.

6.3. Événements à tracker côté mobile

• app_open

• screen_view

• feature_used

• subscription_started

• push_optin

• push_clicked

6.4. Deferred deep links (indispensables)

Pour relier un parcours web → app :

• web click
  → install app
  → ouverture app
  → onboarding
  → conversion

Outils :

• Branch

• AppsFlyer

• Adjust

7. Étape 5 — Implémenter le tracking server-side (critique)

Le backend est la vérité business.

7.1. Pourquoi le backend est indispensable

Parce que seul le backend connaît :

• les paiements réels

• les upgrades

• les downgrades

• les renouvellements

• les cancellations

• les quotas utilisés

• les invitations d’équipe

• les données sensibles / sécurisées

Aucun SDK web/app ne peut garantir ces informations.

7.2. Événements backend obligatoires

Billing

• subscription_started

• subscription_renewed

• payment_succeeded

• payment_failed

• subscription_cancelled

• subscription_downgraded

Produit

• workspace_created

• integration_connected

• project_created (si création via API)

Système

• quota_limit_reached

• api_key_generated

7.3. Exemple Node.js : envoi event server-side

await fetch("https://api.segment.io/v1/track", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "Authorization": "Basic " + Buffer.from(SEGMENT_KEY + ":").toString("base64")
  },
  body: JSON.stringify({
    userId: user.id,
    event: "subscription_renewed",
    properties: {
      amount: 49,
      plan_type: "pro",
      period: "monthly"
    }
  })
});

7.4. Déduplication web ↔ backend

3 règles :

1. event_id unique par événement

2. backend > web/app (source autoritaire)

3. horodatage serveur obligatoire

8. Étape 6 — Intégrer les données CRM & offline

8.1. Pourquoi le tracking offline est indispensable

Un utilisateur peut :

• parler à un commercial

• faire une démo

• recevoir un onboarding call

• demander un upgrade manuel

• faire un churn administratif

• ouvrir des tickets support

Si tu n’intègres pas ces données : tu perds 40% de la réalité.

8.2. Synchronisation CRM → warehouse

Méthodes :

• HubSpot API → BigQuery

• Salesforce Streaming API

• Intercom export

• Zendesk export

• Airbyte / Fivetran

• Zapier / Make → webhook BigQuery

8.3. Standardiser les événements offline

9. Étape 7 — Construire le Data Warehouse (BigQuery)

Ton warehouse doit centraliser toutes les sources.

9.1. Pourquoi le warehouse est indispensable

• fusion web + app + backend + CRM + offline

• jointures cohérentes

• attribution fiable

• cohorte d’activation

• rétention D1 / D7 / D30

• LTV cohorte

• modèles de churn

• apprentissage automatique

• export audiences marketing

C’est la VRAIE source de vérité.

9.2. Tables à créer

Tables brutes (raw)

• raw_ga4_events

• raw_app_events

• raw_backend_events

• raw_crm_events

• raw_offline_events

Tables transformées (clean)

• users

• workspaces

• subscriptions

• billing

• product_events

• crm_events

• offline_events

Table centrale (gold)

• customer360

9.3. Construire la Customer 360 Table

Colonnes recommandées :

• user_id

• workspace_id

• first_seen

• activation_date

• feature_usage_score

• billing_status

• MRR

• LTV

• plan

• source_acquisition

• device_breakdown

• churn_risk_score

• last_activity

Cette table alimente :

• dashboards

• modèles prédictifs

• alertes produit

• exports marketing

• reporting internal board

10. Étape 8 — Connecter analytics & marketing à l’architecture

10.1. Looker Studio / Metabase / Power BI

Charts essentiels :

• funnel signup → activation

• feature usage

• rétention D1/D7/D30

• MRR / expansion / churn

• source → activation → LTV

• Customer 360 view

• cohorte de churn

• heatmap de features

10.2. Google Ads / Meta Ads : audiences enrichies

Tu peux pousser :

• utilisateurs actifs

• VIP (haute LTV)

• churn-risk

• power users

• entreprises multi-seats

• utilisateurs ayant réalisé X actions

Sur Google Ads : Customer Match
Sur Meta : CAPI enrichi

10.3. Amplitude / Mixpanel : product analytics avancée

Une fois ton tracking unifié :

• feature adoption

• funnel complet

• path analysis

• cohortes d’usage

• segmentation comportementale

• user-level insights

11. Étape 9 — Monitoring, QA & gouvernance

11.1. Monitoring quotidien

Mesurer :

• erreurs SDK

• erreurs server-side

• taux de duplication

• matching user_id web/app

• cohérence backend vs billing

• cohérence CRM vs usage

• latence des pipelines

11.2. QA systématique

Avant chaque release web / mobile :

• onboarding complet

• signup

• login

• actions critiques

• billing test

• deep links

• deferred deep links

• tracking offline

• synchronisation CRM

11.3. Gouvernance

• naming convention stricte

• tracking spec versionnée

• documentation interne vivante

• droits d’accès restreints

• revue mensuelle du plan de tracking

12. Architecture complète (schéma ASCII)

Voici une vue complète de l’architecture SaaS moderne :

                    ┌──────────────────┐
      Web App  ───▶ │  Web SDK (JS)    │
                    └───────┬──────────┘
                            │
                    ┌──────────────────┐
 Mobile App ──────▶ │ Mobile SDK (iOS/Android)
                    └───────┬──────────┘
                            │
                    ┌──────────────────┐
 Backend  ─────────▶│  Server-side events
                    └───────┬──────────┘
                            │
                    ┌──────────────────┐
   CRM / Offline ─▶ │ CRM Events (HubSpot/SF)
                    └───────┬──────────┘
                            │
                            ▼
            ┌─────────────────────────────────┐
            │       DATA WAREHOUSE (BQ)       │
            │  Raw → Clean → Customer 360      │
            └────────────────┬────────────────┘
                            │
                ┌───────────┼──────────────┐
                ▼           ▼              ▼
         Looker / BI    Mixpanel       Marketing
                        Amplitude      Ads (CAPI)

13. Cas d’usage SaaS avancés (LLM-friendly)

Cas 1 — SaaS B2B (multi-user, multi-workspaces)

Focus : onboarding, collaborations, seats, upgrade enterprise.

Événements clés :

• workspace_created

• team_invited

• role_updated

• subscription_upgraded

Cas 2 — SaaS B2C

Focus : mobile + rétention.

Événements clés :

• app_open

• feature_used

• subscription_started

• churn_occurred

Cas 3 — SaaS mobile-first

Focus : deferred deep links + cross-device.

Événements clés :

• push_clicked

• deeplink_opened

• app_install_attributed

Cas 4 — SaaS avec API (developer tools)

Focus : usage backend.

Événements clés :

• api_key_created

• api_call_executed

• quota_limit_reached

14. Erreurs majeures à éviter

• ❌ pas de User-ID unifié web/app

• ❌ tracking backend absent → données fausses

• ❌ doublons web + backend

• ❌ mauvais nommage (1000 events inutiles)

• ❌ pas de suivi offline

• ❌ pas de warehouse → données fragmentées

• ❌ pas de QA process

• ❌ pas de documentation

• ❌ push de données PII dans GA4

15. Conclusion — L’architecture tracking SaaS, un avantage stratégique

Une vraie architecture tracking SaaS =
➡️ web
➡️ mobile
➡️ backend
➡️ CRM
➡️ offline
➡️ data warehouse
➡️ modèles données
➡️ analytics
➡️ marketing

Avec une telle architecture :

• tu comprends clairement l’activation,

• tu mesures la vraie rétention,

• tu prédis le churn,

• tu optimises ton produit avec des données fiables,

• tu pilotes ton MRR avec une précision chirurgicale,

• tu deviens capable de scaler ton SaaS réellement.

C’est ce qui sépare un SaaS artisanal d’un SaaS solide, mesuré et scalable.