“Basedash, c'est l'analyste data qu'on n'a jamais eu à embaucher. C'est la première chose que j'ouvre chaque matin.”

Parallel est le réseau de distribution TikTok pour les marques. Plutôt que de dépendre d’un seul compte de marque, Parallel gère un réseau de plus de 10 000 comptes organiques qui publient du contenu pour des clients des centaines de milliers de fois chaque mois — représentant environ 0,2 % de toutes les publications quotidiennes sur TikTok. Le résultat : du contenu au style organique livré à l’échelle et avec la constance de la publicité payante, pour une fraction du CPM. Parallel fait tourner des programmes pour de grandes marques CPG et des applications grand public.

Faire fonctionner un réseau de cette ampleur produit une quantité énorme de données. Chaque compte, publication, template, son et campagne de marque a ses propres métriques, et chacune d’entre elles peut être le levier qui fait fonctionner une campagne ou la fait discrètement s’arrêter. Peter Solimine, co-fondateur et CEO, avait besoin d’un moyen d’interroger tout cela sans détourner les ingénieurs du produit ni construire encore un dashboard interne.

« Toute notre activité, c’est du contenu qui circule à travers des comptes. Si vous ne pouvez pas voir ce qui se passe au niveau de la publication et du compte, vous volez à l’aveugle. »

Avant Basedash

Les données de production de Parallel vivent dans Postgres sur Supabase. Derrière chaque publication virale se cache une chaîne d’enregistrements structurés — le compte qui l’a publiée, le template dont elle est issue, le son qu’elle utilise, le client pour lequel elle a été faite, les vues et conversions qu’elle a générées. Des données utiles, mais pas utiles du tout si le seul moyen de les interroger, c’est d’écrire du SQL à la main ou d’ouvrir un ticket auprès de l’ingénierie.

Au début, c’est exactement ce qui se passait. La plupart des questions non triviales sur la performance du réseau passaient par l’ingénierie, ce qui veut dire que la plupart des questions n’étaient jamais posées. Le coût pour trouver une réponse était plus élevé que le coût de deviner — un compromis familier dans n’importe quelle startup à forte intensité opérationnelle, et un compromis coûteux quand votre activité repose sur l’expérimentation continue.

Pourquoi Basedash

Peter a pointé Basedash sur la base Postgres de Parallel et a immédiatement disposé d’une interface conversationnelle sur les mêmes données qui alimentent la plateforme de distribution. Il n’y avait pas de documentation de schéma à écrire, pas de dashboards à scoper, et pas de projet d’ingénierie à approuver — juste des questions et des réponses.

« Je peux demander n’importe quoi à Basedash sur le réseau et obtenir une réponse en quelques secondes. Le genre de questions qui semblaient trop coûteuses à poser avant — comment performent les comptes de ce groupe cette semaine, quels templates génèrent des vues pour ce client, où les URLs de sons échouent — ça arrive maintenant tout simplement. »

Aujourd’hui, Peter mène des conversations régulières à travers toute l’activité, et une part croissante de l’équipe s’en sert pour ses propres questions à travers le produit, les opérations et la gestion de comptes.

Ce que Parallel demande vraiment à Basedash

Les questions que Parallel fait passer par Basedash sont spécifiques à la réalité opérationnelle de faire tourner un grand réseau de contenu distribué :

• Performance de contenu. Quels templates, sons et publications génèrent le plus de vues et de conversions, découpés par client, groupe de comptes, heure de la journée et plateforme.
• Santé des comptes. Identifier les comptes morts, les comptes actifs sans vue, et les groupes discrètement sous-performants — le genre d’hygiène de réseau qui devient invisible si personne ne regarde activement.
• Reporting par client. Récupérer des vues dédiées de la performance de chaque programme de marque, de la cadence de publication et du mix de templates aux publications les plus performantes.
• Intégrité opérationnelle. Repérer les URLs de sons cassées, les assets défectueux et les problèmes de qualité de données dans le pipeline de publication avant qu’ils ne deviennent un problème de campagne.

« C’est la première chose que j’ouvre le matin. Je fais tourner quelques conversations avant ma première réunion, juste pour voir ce qui se passe sur le réseau. »

Une culture data pilotée par le fondateur

La plupart des outils analytics visent les équipes data. Basedash fonctionne pour les opérateurs. Pour Peter, cette distinction est tout l’enjeu — en tant que fondateur d’une entreprise construite sur la gestion de dizaines de milliers de comptes en parallèle, il a besoin de la puissance analytique d’une équipe data sans sa latence.

L’interface conversationnelle laisse les questions évoluer naturellement. Une simple consultation (« combien de publications ce client a-t-il eues hier ») devient une investigation (« quels comptes sous-performent pour ce client cette semaine, et y a-t-il un template ou un son en commun ») sans jamais changer d’outil ni écrire de requête.

« Chaque minute que je gagne sur l’analyse, c’est une minute que je récupère pour l’activité réelle. Basedash multiplie ça à travers toute l’équipe. »

Impact

Depuis l’adoption de Basedash, Parallel a construit une couche analytics self-service au-dessus de sa plateforme de distribution de contenu :

• Le CEO répond lui-même à ses questions sur le réseau chaque jour, sans écrire de SQL ni ouvrir de ticket
• Une visibilité en temps réel sur la santé des comptes, la performance du contenu et les résultats par client à travers des milliers de comptes gérés
• Du temps d’ingénierie récupéré pour le travail produit plutôt que pour des demandes de données ponctuelles
• Des problèmes opérationnels comme des sons cassés et des publications échouées, détectés tôt parce qu’ils sont faciles à surveiller
• Une part croissante de l’équipe qui fait sa propre analyse en self-service au lieu de passer par une seule personne

« Basedash a transformé la couche de données de notre entreprise en quelque chose de self-service. Pour une activité aussi opérationnelle que la nôtre, c’est la différence entre deviner et savoir. »