Generelt kan folk ikke lide at modtage uopfordrede e-mails. Ikke desto mindre abonnerer de nogle gange på nyhedsbreve for at få rabat eller for at holde sig ajour med nye produkter. Denne artikel vil præsentere en tilgang til at designe en nyhedsbrevsdatabase.
Hvorfor bekymre sig om nyhedsbrevs-e-mails?
Nyhedsbrevsabonnenter repræsenterer en ekstremt værdifuld gruppe af kunder - de er interesserede i vores produkter, de stoler på os, og de bruger tid på at gennemgå vores tilbud og kampagner. Hvad mere er, at sende e-mails til kunder er et af de billigste værktøjer inden for online markedsføring. Det skal dog gøres omhyggeligt – data skal opdateres dagligt (fordi folk abonnerer og afmelder sig) og være af høj kvalitet (vi ønsker ikke at sende uønskede e-mails, da det påvirker brandets image negativt).
Så spørgsmålet opstår om, hvordan man styrer denne proces med at få kvalitetsdata og opdatere dem dagligt. Der er mange muligheder ...
Og vinderen er...
Kundeanalyse! I dag er den vigtigste faktor for at være på forkant med konkurrenterne at finde indsigt fra data og træffe forretningsbeslutninger på det grundlag. Ville det ikke være fantastisk at se historien om udsendelser af nyhedsbreve igennem og analysere deres intensitet og effektivitet? For hver kunde? Og så slutte sig til det med købsdata, afdække kundens interesser, udarbejde individuelle anbefalinger og sende disse ud ved hjælp af personlige e-mails?
En sådan tilgang ville helt sikkert øge vores konverteringsrate (CR). Konverteringsraten er en af de vigtigste nøgleresultatindikatorer for online markedsføring; det viser, hvor mange mennesker der foretager et køb efter at have set noget af vores salgsfremmende materiale (annoncer, nyhedsbreve osv.). En høj CR betyder øget forretningseffektivitet.
Nu hvor vi forstår noget af den involverede markedsføring, lad os komme ind i datamodellen!
Lad os begynde at modellere en nyhedsbrevsdatabase!
Når vi graver lige ind, ser vi, at de to hovedtabeller i modellen er client og newsletter tabeller.
Da vi mest vil være interesseret i kundeanalyse, er client bordet skal forblive i midten af modellen. I denne tabel har hver klient deres eget unikke id . Vi gemmer også sådanne oplysninger som klientens first_name og last_name , kontaktoplysninger (email , phone_number , adresse), birthday , create_date (når kundens registrering blev indtastet i databasen) og deres source_id – dvs. om de er registreret på vores side eller en forretningspartner har givet os deres data.
newsletter tabel gemmer data vedrørende hver oprettelse af nyhedsbreve. Nyhedsbreve kan identificeres ud fra deres unikke id . Hver er beskrevet med et name (f.eks. "Ny kollektion af dametøj – efterår 2016"), e-mail subject ("Det mest fashionable tøj til hende – køb nu!"), html_file (filen, der indeholder HTML-koden for det pågældende nyhedsbrev), nyhedsbrev type (f.eks. "ny samling", "fødselsdagsnyhedsbrev") og create_date .
Markedsføringssamtykke
For at kunne udsende markedsføringsoplysninger (per post, telefon, e-mail eller SMS), skal en virksomhed indhente samtykke fra deres kunder. I vores model er samtykker gemt i en separat tabel med navnet marketing_consent . Det opbevarer oplysninger om det aktuelle sæt af markedsføringstilladelser for alle vores kunder. Samtykke er kodet som booleske variable – TRUE (accepterer marketingkommunikation) eller FALSE (ikke enig).
Det er meget vigtigt at gemme oplysninger om, hvornår en kunde har accepteret at modtage annoncer via hver kommunikationskanal. Det er også en fordel at optage, hvornår de trak deres samtykke tilbage for hver kanal. Til sådanne formål er consent_change bord blev designet.
Hver ændring har et unikt id og er tildelt en bestemt klient af deres client_id . Når en klient anmoder om at blive fjernet fra nyhedsbrevs-e-mails, vil nyhedsbrevet id fra channel tabellen vil også blive gemt i consent_change tabellens channel_id attribut. new_consent attribut er en boolesk værdi (TRUE eller FALSE) og repræsenterer nye markedsføringstilladelser.
update_date kolonnen indeholder datoen, hvor en kunde anmodede om en ændring. Denne struktur giver os mulighed for at udtrække et sæt samtykker for alle kunder på en given dag. Det er yderst nyttigt, hvis en klient klager over at modtage en e-mail, efter at de allerede har afmeldt sig vores nyhedsbrev. Med disse oplysninger på fil kan vi kontrollere, hvornår afmeldingen fandt sted, og forhåbentlig bekræfte, at dette blev gjort efter e-mailens nyhedsbrev var blevet sendt.
Hold orden på udsendelser
At designe en perfekt databasemodel til udsendelse af nyhedsbreve er ikke et stykke kage. Hvorfor? Nå, selvfølgelig skal vi være i stand til at identificere enhver enkelt oprettelse af nyhedsbreve (hvilket betyder layout, grafik, produkter, links osv.). Vi ved også, at en kreation kan sendes flere gange:ledere kan beslutte, at en bøtte e-mails sendes om morgenen til halvdelen af kunderne og om aftenen til den anden halvdel. Så det er afgørende at registrere, hvilke kunder der har modtaget hvilket nyhedsbrev og hvornår. Det er derfor, denne del af modellen består af tre tabeller:
newslettertabel – som vi har beskrevet tidligere.newsletter_sendouttabel – som identificerer en enkelt udsendelse. For eksempel julenyhedsbrevet (id =“2512”) blev sendt ud den 10. december kl. 18.00. Denne registrering giver marketingfolk mulighed for at sende det samme nyhedsbrev til separate grupper af kunder på forskellige tidspunkter.sendout_receiverstabel – som indsamler data om modtagerne af hver udsendelse. Der vil være én post for hver e-mail fra hver udsendelse. Hver række har tre kolonner:id(identificerer hændelsen med at sende en e-mail til en klient),client_id(identifikation af klienter fra vores database) ognl_sendout_id(identifikation af udsendelse af nyhedsbrev).
Her er den komplette nyhedsbrevsmodel:
Enhver idé til, hvordan man kan forbedre denne model?
En mulig måde er at tilføje et response bord. Dette ville gemme kundernes reaktioner - uanset om de åbnede e-mailen, klikkede på annoncen eller aldrig så beskeden, fordi den var markeret som spam. Hvor skal vi tilføje response tabel til vores model, og hvilken relation skal anvendes? Del dine tanker i kommentarfeltet nedenfor.