Le coût caché de Warehouse-Native

Au cours des dernières années, mParticle s'est attaché à soutenir les efforts de qualité des données et de gouvernance de nos clients, et nous avons étendu cette approche pour soutenir les stratégies « zéro copie ». Nous déploierons notre propre architecture de superposition CDW spécifiquement à cette fin.

Bien que nous reconnaissions que l'optimisation du stockage des données est importante pour la gouvernance, nous pensons que se concentrer sur l'optimisation des coûts de calcul du CDP afin de maximiser la valeur pour nos clients constitue à la fois un besoin du marché plus pressant et une opportunité bien plus importante. Nous pensons que cela est essentiel, d'autant plus que nous prenons en compte tous les outils de prise de décision utilisant du ML/AI à forte intensité de calcul qui arriveront sur le marché au cours des prochains trimestres.

Au cours de la dernière décennie, nous avons investi d'importantes ressources dans l'optimisation continue de notre architecture informatique, en nous concentrant spécifiquement sur la fourniture de capacités de personnalisation en temps réel à grande échelle. Nous pensons que les spécialistes du marketing à grande échelle en auront besoin pour activer les fonctionnalités d'IA CDP en temps réel. Par conséquent, nous avons mené des recherches pour déterminer les architectures de calcul optimales pour ces cas d'utilisation spécifiques. Bien que l'approche native de l'entrepôt présente certainement certaines caractéristiques souhaitables, héritant principalement des caractéristiques de qualité et de gouvernance sous-jacentes du CDW, elle n'est pas hautement optimisée et ne peut pas l'être pour les applications en temps réel mises à l'échelle. Malgré nos efforts d'optimisation, nos recherches montrent le profil de coût suivant pour le déploiement d'audiences avec différentes latences d'actualisation :

Line graph titled "Total Compute Costs – Composable CDP Architecture" comparing cost growth as update frequency increases from monthly to real-time. Costs rise exponentially, especially with higher audience counts (10, 50, 100, 200). At daily updates, compute costs can be 25x to 50x higher, as highlighted by callouts on the chart.

Ce graphique montre que le fait de passer des actualisations quotidiennes de l'audience à des actualisations horaires peut entraîner une augmentation des coûts de calcul de 25 fois. Passer des synchronisations quotidiennes à des synchronisations de cinq minutes, ce qui se rapproche le plus des actualisations en temps réel (ce qui n'est pas réellement réalisable dans les architectures natives actuelles des entrepôts), multiplie les coûts au moins par 50. Une autre observation importante est l'accélération des coûts qui se produit lors de l'amélioration des vitesses de rafraîchissement inférieures à 24 heures.

Bien que les CDP natifs des entrepôts bénéficient d'un modèle de tarification qui ne doit pas nécessairement refléter ces coûts, leurs clients les paient. Beaucoup commencent à remarquer ces effets sur leurs coûts de calcul CDW. Cela ne fera qu'être exacerbé par les applications ML/AI, qui sont gourmandes en ressources de calcul. Compte tenu de notre vision à long terme d'un CDP IA agentique, qui exploite des signaux de données en temps réel, nous ne sommes pas convaincus que les architectures composables actuelles constituent la meilleure approche.

Pour les clients du CDP, la principale question à se poser est de savoir si des applications marketing à faible latence sont nécessaires pour atteindre leurs objectifs stratégiques. Ce sera certainement le cas si vos transactions sont peu coûteuses ou si vos parcours clients sont très interactifs. Plus précisément, aurez-vous probablement besoin d'une variété de segments d'audience capable de se mettre à jour à la même vitesse que vos clients interagissent ? Si tel est le cas, ce profil de coûts de calcul devrait présenter un grand intérêt et être étudié, car il limiterait autrement les capacités de marketing via une solution native d'entrepôt.

À plus long terme, les architectures Lakehouse ou Data Mesh constitueront le principal mécanisme de gestion des coûts de calcul. Dans ces architectures, les moteurs de calcul optimisés accèdent à un magasin de données universel, probablement basé sur Delta Lake ou Iceberg. Un moteur de calcul CDP optimisé sera l'architecture préférée pour les applications marketing avancées. C'est la feuille de route que poursuit mParticle.

Alors que le débat a fait rage ces dernières années sur les avantages, les coûts, les avantages et les compromis des différentes approches CDP, nous souhaitons fournir des preuves tangibles de la différence de coût entre les solutions optimisées pour le calcul et les alternatives. Nous publierons les résultats complets dans les semaines à venir, restez à l'affût.

No items found.
Précédent
Suivant
Le prochain de la série

CDP 2.0 et Zero Dechet

Lisez l'article