Suivi d'événements pour MVP sur Django et SQLite : analyses rapides

Traqueur d'événements minimaliste pour MVP : Django, SQLite et pixel de suivi

Lors du lancement d'un MVP, il est essentiel de valider rapidement et à moindre coût les actions clés des utilisateurs. Plutôt que d'intégrer des plateformes d'analyse lourdes, déployez un backend Django léger qui collecte les événements via un pixel de suivi et les stocke en SQLite. Cette approche fait gagner du temps, évite les infrastructures complexes et vous permet de vous concentrer sur la validation de votre hypothèse principale.

Architecture d'un traqueur d'événements simple

La solution repose sur un backend minimaliste déployé une seule fois sur un service d'hébergement pour supporter plusieurs frontends. Le frontend envoie une requête GET vers l'endpoint /t.gif avec les paramètres événement et source. Le backend incrémente atomiquement un compteur en base de données. Consultez les stats via l'endpoint protégé /api/stats, qui renvoie des données JSON.

Composants clés du système :

• Frontend : Appelle track(event, src) en créant un objet Image.
• Backend (Django) : Gère la requête et met à jour le compteur en SQLite.
• Base de données : Table unique avec les champs event, src, count et updated_at.
• API Stats : Accès authentifié par clé aux données agrégées.

Ce traqueur excelle pour les projets sur hébergements gratuits où le système de fichiers est éphémère et les services s'endorment après inactivité.

Implémentation avec Django et SQLite

Le modèle de données est ultra-simple, avec un index unique sur la paire event et src.

# tracker/models.py
from django.db import models

class Counter(models.Model):
    event = models.CharField(max_length=120)
    src = models.CharField(max_length=120, blank=True, default="")
    count = models.PositiveBigIntegerField(default=0)
    updated_at = models.DateTimeField(auto_now=True)

    class Meta:
        unique_together = ("event", "src")

    def __str__(self) -> str:
        return f"{self.src}:{self.event}={self.count}"

L'endpoint de journalisation d'événements sert un pixel 1×1 encodé en base64 pour contourner les problèmes CORS et éviter les bibliothèques client supplémentaires.

# tracker/views.py
import base64

from django.conf import settings
from django.db import transaction
from django.db.models import F
from django.http import HttpResponse, JsonResponse
from django.views.decorators.http import require_GET

from .models import Counter

_GIF_1x1 = base64.b64decode(
    "R0lGODlhAQABAPAAAAAAAAAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw=="
)

@require_GET
def pixel(request):
    event = _clean(request.GET.get("e", ""), 120)
    src = _clean(request.GET.get("src", ""), 120)

    if not event:
        return _gif_response()

    with transaction.atomic():
        obj, created = Counter.objects.get_or_create(event=event, src=src)

        if created:
            obj.count = 1
            obj.save(update_fields=["count"])
        else:
            Counter.objects.filter(pk=obj.pk).update(count=F("count") + 1)

    return _gif_response()

Les mises à jour atomiques via F("count") + 1 garantissent l'intégrité des données sous requêtes concurrentes. L'endpoint stats filtre par événement et source si les paramètres sont fournis.

Intégration frontend avec Next.js

Côté client, une fonction d'aide portable fonctionne inchangée dans tous les projets.

// src/utils/track.ts
const TRACK_BASE = "https://your-domain.com/t.gif";

export const track = (event: string, src: string) => {
  const img = new Image();
  img.src =
    `${TRACK_BASE}?` +
    `e=${encodeURIComponent(event)}` +
    `&src=${encodeURIComponent(src)}` +
    `&t=${Date.now()}`;
};

Exemple dans un composant Next.js pour tracker les clics sur le bouton de création de projet :

// src/app/_ui/HomePageClient.tsx
"use client";

import { useRouter } from "next/navigation";
import { track } from "@/utils/track";

export default function HomePageClient() {
  const router = useRouter();

  return (
    <section className="mt-8 space-y-2">
      <div
        className="app-card app-card--soft cursor-pointer hover:border-slate-500/70 hover:bg-white/5 transition-colors"
        role="button"
        tabIndex={0}
        onClick={() => {
          router.push("/demo");
          track("create_project_click", "demo_project");
        }}
      >
        Créer un projet
      </div>
    </section>
  );
}

Récupérez les stats en appelant /api/stats avec une clé d'authentification. La réponse liste les événements avec leurs compteurs et dates de dernière mise à jour.

Avantages et limites de cette approche

Un traqueur léger pour MVP offre des gains concrets :

• Test d'hypothèse rapide : Focalisez-vous sur une action clé au lieu de métriques infinies.
• Économies de ressources : Pas besoin d'outils d'analyse gonflés ou de bases séparées.
• Polyvalence : Un seul backend sert plusieurs frontends et projets.
• Déploiement facile : Besoins minimaux en hébergement — idéal pour les offres gratuites.

Mais il a des limites naturelles :

• Pas de suivi d'utilisateurs uniques ou de sessions.
• Absence d'entonnoirs, de rétention ou de segmentation.
• Pas de tests A/B ou de rapports avancés.

Ajoutez-les plus tard, une fois le MVP validé.

Points clés à retenir

• Une métrique vaut mieux que vingt : Pour un MVP, ciblez une action centrale qui teste votre hypothèse principale.
• Infrastructure légère : SQLite et un pixel évitent les galères de déploiement.
• Opérations atomiques : F("count") + 1 maintient les données cohérentes sous charge.
• Helper portable : 10 lignes de code client s'adaptent à n'importe quel framework frontend moderne.
• Lancement express : Déployez en heures et commencez à collecter des données immédiatement.

Ce traqueur ne remplace pas les suites d'analyse complètes, mais répond à la question essentielle à bas coût : l'action clé se produit-elle ? Sinon, le problème vient probablement du produit, pas du manque de métriques.

— Editorial Team