Over het algemeen ontvangen mensen niet graag ongevraagde e-mails. Toch abonneren ze zich soms op nieuwsbrieven om korting te krijgen of om op de hoogte te blijven van nieuwe producten. Dit artikel presenteert een benadering voor het ontwerpen van een nieuwsbriefdatabase.
Waarom zorgen maken over nieuwsbrief-e-mails?
Nieuwsbriefabonnees vertegenwoordigen een uiterst waardevolle groep klanten – ze zijn geïnteresseerd in onze producten, ze vertrouwen ons en ze besteden tijd aan het beoordelen van onze aanbiedingen en promoties. Bovendien is het verzenden van e-mails naar klanten een van de goedkoopste tools in online marketing. Het moet echter zorgvuldig worden gedaan - gegevens moeten dagelijks worden bijgewerkt (omdat mensen zich aan- en afmelden) en van hoge kwaliteit zijn (we willen geen ongewenste e-mails verzenden, omdat dit een negatief effect heeft op het merkimago).
De vraag rijst dus hoe dit proces van het verkrijgen van kwaliteitsgegevens en het dagelijks bijwerken ervan, moet worden beheerd. Er zijn veel opties ...
En de winnaar is...
Klantanalyses! Tegenwoordig is de belangrijkste factor om de concurrentie voor te blijven het vinden van inzichten uit data en het op basis daarvan nemen van zakelijke beslissingen. Zou het niet geweldig zijn om door de geschiedenis van nieuwsbriefverzendingen te kijken en hun intensiteit en effectiviteit te analyseren? Voor elke klant? En die vervolgens samenvoegen met aankoopgegevens, de interesses van de klant ontdekken, individuele aanbevelingen opstellen en deze via gepersonaliseerde e-mails versturen?
Een dergelijke aanpak zou zeker onze conversieratio (CR) verhogen. De conversieratio is een van de belangrijkste prestatie-indicatoren voor online marketing; het laat zien hoeveel mensen een aankoop doen na het zien van ons promotiemateriaal (advertenties, nieuwsbrieven, enz.). Een hoge CR betekent een grotere zakelijke effectiviteit.
Nu we een deel van de betrokken marketing begrijpen, gaan we in op het datamodel!
Laten we beginnen met het modelleren van een nieuwsbriefdatabase!
Als we er meteen in duiken, zien we dat de twee hoofdtabellen in het model de client en newsletter tabellen.
Omdat we vooral geïnteresseerd zijn in klantanalyse, is de client tafel moet in het midden van het model blijven. In deze tabel heeft elke klant zijn eigen unieke id . We slaan ook informatie op zoals de first_name . van de klant en last_name , contactgegevens (email , phone_number , adres), birthday , create_date (wanneer het record van de klant in de database werd ingevoerd) en hun source_id – d.w.z. of ze zich op onze site hebben geregistreerd of dat een zakenpartner ons hun gegevens heeft verstrekt.
De newsletter table slaat gegevens op over elke creatie van een nieuwsbrief. Nieuwsbrieven kunnen worden geïdentificeerd op basis van hun unieke id . Elk wordt beschreven door een name (bijv. "Nieuwe dameskledingcollectie – herfst 2016"), e-mail subject (“De meest modieuze kleding voor haar – koop nu!”), html_file (het bestand met de HTML-code voor die specifieke nieuwsbrief), nieuwsbrief type (bijv. "nieuwe collectie", "verjaardagsnieuwsbrief") en de create_date .
Marketingtoestemmingen
Om marketinginformatie te verzenden (per post, telefoon, e-mail of sms), moet een bedrijf toestemming krijgen van zijn klanten. In ons model worden toestemmingen opgeslagen in een aparte tabel met de naam marketing_consent . Het houdt informatie bij over de huidige set marketingtoestemmingen voor al onze klanten. Toestemmingen worden gecodeerd als booleaanse variabelen - WAAR (gaat akkoord met marketingcommunicatie) of ONWAAR (niet akkoord).
Het is erg belangrijk om informatie op te slaan over wanneer een klant heeft ingestemd met het ontvangen van advertenties via elk communicatiekanaal. Het is ook nuttig om vast te leggen wanneer ze hun toestemming voor elk kanaal hebben ingetrokken. Voor dergelijke doeleinden is de consent_change tafel is ontworpen.
Elke wijziging heeft een unieke id en wordt toegewezen aan een bepaalde klant door hun client_id . Wanneer een klant verzoekt om te worden verwijderd uit nieuwsbrief-e-mails, wordt de nieuwsbrief id van het channel tabel wordt ook opgeslagen in de consent_change tabel's channel_id attribuut. De new_consent attribuut is een booleaanse waarde (TRUE of FALSE) en vertegenwoordigt nieuwe marketingtoestemmingen.
De update_date kolom bevat de datum waarop een klant een wijziging heeft aangevraagd. Met deze structuur kunnen we een reeks toestemmingen voor alle klanten op een bepaalde dag extraheren. Het is erg handig als een klant klaagt over het ontvangen van een e-mail nadat hij zich al heeft afgemeld voor onze nieuwsbrief. Met deze informatie in ons bestand kunnen we controleren wanneer het afmelden heeft plaatsgevonden en hopelijk bevestigen dat dit is gebeurd nadat de e-mailnieuwsbrief is verzonden.
Uitzendingen op orde houden
Het ontwerpen van een perfect databasemodel voor het versturen van nieuwsbrieven is geen fluitje van een cent. Waarom? Welnu, natuurlijk moeten we elke creatie van een nieuwsbrief kunnen identificeren (wat betekent lay-out, afbeeldingen, producten, links, enz.). We weten ook dat een creatie meerdere keren kan worden verzonden:managers kunnen besluiten dat de ene emmer met e-mails 's ochtends naar de helft van de klanten wordt gestuurd en' s avonds naar de andere helft. Het is dus cruciaal om vast te leggen welke klanten welke nieuwsbrief wanneer hebben ontvangen. Daarom bestaat dit deel van het model uit drie tabellen:
- De
newslettertabel – die we eerder beschreven. - De
newsletter_sendouttabel - die een enkele verzending identificeert. Bijvoorbeeld de kerstnieuwsbrief (id =“2512”) is op 10 december om 18.00 uur per e-mail verzonden. Door deze gegevens bij te houden, kunnen marketeers dezelfde nieuwsbrief op verschillende tijdstippen naar verschillende groepen klanten sturen. - De
sendout_receiverstabel – die gegevens verzamelt over de ontvangers van elke verzending. Er zal één record zijn voor elke e-mail van elke verzending. Elke rij heeft drie kolommen:id(identificatie van de gebeurtenis van het verzenden van een e-mail naar een klant),client_id(klanten identificeren uit onze database) ennl_sendout_id(identificatie van een verzonden nieuwsbrief).
Hier is het complete nieuwsbriefmodel:
Ideeën om dit model te verbeteren?
Een mogelijke manier is om een response tafel. Dit zou de reacties van klanten opslaan - of ze nu de e-mail hebben geopend, op de advertentie hebben geklikt of het bericht nooit hebben gezien omdat het als spam was gemarkeerd. Waar moeten we het response tabel toe aan ons model en welke relatie moet worden toegepast? Deel uw mening in het commentaargedeelte hieronder.