In generale, alle persone non piace ricevere e-mail non richieste. Tuttavia, a volte si iscrivono alle newsletter per ottenere uno sconto o per tenersi aggiornati sui nuovi prodotti. Questo articolo presenterà un approccio alla progettazione di un database di newsletter.
Perché preoccuparsi delle e-mail della newsletter?
Gli abbonati alla newsletter rappresentano un gruppo di clienti estremamente prezioso:sono interessati ai nostri prodotti, si fidano di noi e passano il tempo a rivedere le nostre offerte e promozioni. Inoltre, inviare e-mail ai clienti è uno degli strumenti più economici nel marketing online. Tuttavia, deve essere fatto con attenzione:i dati devono essere aggiornati quotidianamente (perché le persone si iscrivono e annullano l'iscrizione) ed essere di alta qualità (non vogliamo inviare e-mail indesiderate, poiché influiscono negativamente sull'immagine del marchio).
Quindi sorge la domanda su come gestire questo processo di ottenere dati di qualità e aggiornarli quotidianamente. Ci sono molte opzioni...
E il vincitore è...
Analisi dei clienti! Al giorno d'oggi, il fattore più importante per stare al passo con la concorrenza è trovare informazioni dai dati e prendere decisioni aziendali su queste basi. Non sarebbe bello esaminare la cronologia degli invii di newsletter e analizzarne l'intensità e l'efficacia? Per ogni cliente? E poi unisciti ai dati sugli acquisti, scopri gli interessi del cliente, prepara raccomandazioni individuali e inviale tramite e-mail personalizzate?
Un tale approccio aumenterebbe sicuramente il nostro tasso di conversione (CR). Il tasso di conversione è uno dei più importanti indicatori chiave di performance del marketing online; mostra quante persone effettuano un acquisto dopo aver visto parte del nostro materiale promozionale (annunci, newsletter, ecc.). Un CR elevato significa una maggiore efficacia aziendale.
Ora che comprendiamo parte del marketing coinvolto, entriamo nel modello dei dati!
Iniziamo a modellare un database di newsletter!
Scavando direttamente, vediamo che le due tabelle principali nel modello sono il client e newsletter tabelle.
Poiché saremo principalmente interessati all'analisi del cliente, il client la tabella dovrebbe rimanere al centro del modello. In questa tabella, ogni cliente ha il proprio id univoco . Conserveremo anche informazioni come il first_name del cliente e last_name , informazioni di contatto (email , phone_number , indirizzo), birthday , create_date (quando il record del cliente è stato inserito nel database) e il loro source_id – ovvero se si sono registrati sul nostro sito o se qualche partner commerciale ci ha fornito i propri dati.
La newsletter la tabella memorizza i dati relativi ad ogni creazione di newsletter. Le newsletter possono essere identificate in base al loro id univoco . Ciascuno è descritto da un name (ad es. "Nuova collezione di abbigliamento femminile - Autunno 2016"), inviare un'e-mail a subject (“I vestiti più alla moda per lei – compralo subito!”), html_file (il file contenente il codice HTML di quella particolare newsletter), newsletter type (es. “nuova collezione”, “newsletter di compleanno”) e il create_date .
Consenso al marketing
Per inviare informazioni di marketing (per posta, telefono, e-mail o SMS), un'azienda deve ottenere il consenso dei propri clienti. Nel nostro modello, i consensi sono memorizzati in una tabella separata denominata marketing_consent . Conserva le informazioni sull'attuale serie di consensi di marketing per tutti i nostri clienti. I consensi sono codificati come variabili booleane:VERO (accetta alla comunicazione di marketing) o FALSO (non accetta).
È molto importante memorizzare le informazioni relative a quando un cliente ha accettato di ricevere annunci pubblicitari tramite ciascun canale di comunicazione. È anche utile registrare quando hanno ritirato il loro consenso per ciascun canale. A tal fine, il consent_change è stato progettato il tavolo.
Ogni modifica ha un id univoco ed è assegnato a un particolare cliente dal suo client_id . Quando un cliente richiede di essere rimosso dalle email della newsletter, la newsletter id dal channel la tabella verrà anche archiviata nel consent_change channel_id della tabella attributo. Il new_consent l'attributo è un valore booleano (TRUE o FALSE) e rappresenta i nuovi consensi di marketing.
Il update_date la colonna contiene la data in cui un cliente ha richiesto una modifica. Questa struttura ci consente di estrarre una serie di consensi per tutti i clienti in un determinato giorno. È estremamente utile se un cliente si lamenta di aver ricevuto un'e-mail dopo che si era già cancellato dalla nostra newsletter. Con queste informazioni in archivio, possiamo controllare quando è avvenuta l'annullamento dell'iscrizione e, si spera, confermare che ciò sia stato fatto dopo l'invio della newsletter via email.
Mantenere in ordine gli invii
Progettare un modello di database perfetto per l'invio di newsletter non è un gioco da ragazzi. Come mai? Bene, ovviamente dobbiamo essere in grado di identificare ogni singola creazione di newsletter (che significa layout, grafica, prodotti, link, ecc.). Sappiamo anche che una creazione può essere inviata più volte:i gestori possono decidere che un secchio di e-mail verrà inviato la mattina a metà dei clienti e la sera all'altra metà. Quindi è fondamentale registrare quali clienti hanno ricevuto quale newsletter e quando. Ecco perché questa parte del modello è composta da tre tabelle:
- Il
newslettertabella – che abbiamo descritto in precedenza. - Il
newsletter_sendouttabella – che identifica un unico invio. Ad esempio, la newsletter di Natale (id =“2512”) è stato inviato via e-mail il 10 dicembre alle 18:00. Questa registrazione consente agli esperti di marketing di inviare la stessa newsletter a gruppi separati di clienti in momenti diversi. - Il
sendout_receiverstabella – che raccoglie i dati sui destinatari di ogni invio. Ci sarà un record per ogni email da ogni invio. Ogni riga ha tre colonne:id(identificando l'evento di invio di un'e-mail a un client),client_id(identificazione dei clienti dal nostro database) enl_sendout_id(identificazione di un invio newsletter).
Ecco il modello di newsletter completo:
Qualche idea su come migliorare questo modello?
Un modo possibile è aggiungere una response tavolo. Ciò memorizzerebbe le reazioni dei clienti, indipendentemente dal fatto che abbiano aperto l'e-mail, fatto clic sull'annuncio o non abbiano mai visto il messaggio perché contrassegnato come spam. Dove dovremmo aggiungere la response tabella al nostro modello e quale relazione dovrebbe essere applicata? Condividi i tuoi pensieri nella sezione commenti qui sotto.
