lundi 26 août 2013

Conseil 33: Transformer les mesures du CRM en étiquette de comportement

Nous allons décrire un exemple simple et classique d'attribution d'étiquette de comportement à des modèles complexes de micro-transactions découlant de processus qui interagissent avec  les clients, tels que les centres d'appels, les visites de sites web, les systèmes de livraison, et les systèmes de réconciliation de paiement. Nous allons utiliser nos techniques de reporting d'entrepôt de données standard pour synthétiser trois indicateurs de comportement des clients: récence, fréquence et intensité. La récence mesure la façon dont nous avons récemment collaboré avec le client. Prenons un point de vue large et analysons toute transaction issue des processus que nous avons mentionné ci-dessus. La mesure réelle de récence est le nombre de jours écoulés depuis le dernier contact avec le client.

De même, la fréquence mesure combien de fois nous avons interagi avec le client, reprenant la même perspective que ci-dessus. Et enfin, l'intensité mesure la productivité des interactions qui ont eu lieu. La mesure la plus évidente de l'intensité est le montant total des achats, mais peut-être que le nombre total de pages Web visités est une bonne mesure de l'intensité également.

lundi 19 août 2013

Conseil 32: Faire le travail lors de la phase d'extraction

Notre mission en tant que concepteurs d'entrepôt de données est de publier des données le plus efficacement. Cela signifie placer les données dans le format et le cadre qui est le plus facile à utiliser pour les utilisateurs finaux et les développeurs d'applications.

Dans l'arrière-salle de notre entrepôt de données, nous devons lutter contre nos tendances minimalistes naturelles lorsque nous préparons les données relatives à la consommation finale par les utilisateurs finaux et les développeurs d'applications. Dans de nombreux cas importants, nous devrions accepter:
  • l'augmentation des processus d'alimentation
  • l'augmentation des besoins de stockage

en échange de:
  • schémas symétriques et prévisible que les utilisateurs comprennent
  • la réduction de la complexité de l'application
  • l'amélioration des performances des requêtes et des rapports
La réalisation de ces compromis devrait être un objectif évident pour l'architecte d'entrepôt de données. Un bon architecte d'entrepôt de données résistera à l'envie de déléguer les analyses supplémentaires et la manipulation de tables aux utilisateurs finaux et aux concepteurs d'applications. Méfiez-vous des vendeurs qui militent en faveur de schémas complexes! Mais bien sûr, ces compromis doivent être choisis judicieusement. Regardons une demi-douzaine de situations où nous faisons juste assez de travail au moment de l'extraction pour vraiment faire une différence. Nous allons aussi essayer de définir quelques limites, afin de savoir quand il ne faut pas trop en faire pour éviter de gâcher le résultat final. Nous allons commencer par quelques petits exemples puis nous étendrons progressivement notre périmètre.

lundi 12 août 2013

Conseil 31: Conception d'une partition en temps réel

Même si l'écart de temps entre les systèmes OLTP de production et l'entrepôt de données a diminué dans la plupart des cas, à 24 heures, les besoins avides de nos utilisateurs du marketing nécessitent que l'entrepôt de données comble cette lacune avec des données en temps réel.

La plupart des concepteurs d'entrepôts de données sont sceptiques quant à exécuter les taches d'alimentation existantes de l'ETL (extract-transform-load) toutes les 15 minutes au lieu de toutes les 24 heures. Les concepteurs d'entrepôt de données répondent à ce problème en construisant une partition en temps réel en face de l'entrepôt de données.

lundi 5 août 2013

Conseil 30: Mettez vos tables de faits au régime

Au milieu des années 1990, avant internet, il semblait que l'explosion des données pourrait finalement décroître  A cette époque, nous étions en train d'apprendre à capturer chaque appel téléphonique, chaque article vendu à une caisse enregistreuse, chaque transaction d'actions à Wall Street, et toutes les transactions de polices par d'énormes compagnies d'assurance. Il est vrai que nous n'avons pas souvent conservé une très longue période de certaines de ces sources de données dans nos entrepôts de données, mais il y avait un sentiment que peut-être nous avions atteint une sorte de limite physique à la granularité des données. Peut-être que nous avions enfin rencontré les vrais "atomes" des données.

Eh bien, ce point de vue était évidemment faux. Nous savons maintenant qu'il n'y a pas de limite à la quantité de données que nous pouvons recueillir. Chaque mesure peut être remplacée par toute une série de sous-mesures plus fines. Sur le web, dans les Weblogs nous voyons chaque geste effectué par un visiteur avant qu'il regarde et achète un produit. Nous avons remplacé l'enregistrement unique d'achat de produit par une douzaine ou une centaine d'enregistrements de suivi du comportement. Le pire, c'est que les gens du marketing adorent ces enregistrements de suivi du comportement, et ils veulent en faire toutes sortes d'analyses.