Feb 19 2019

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

Salesforce per tutti o errore tecnico?

autore: Marco Cilia categoria: ga-premium tag: , ,

Da qualche giorno molte property Google Analytics mostrano nel pannello di amministrazione una voce nuova: Salesforce Marketing Cloud. La cosa è strana perché le integrazioni tra la suite Salesforce e GA sono riservate ai possessori di GA 360, mentre la nuova voce è visibile anche sugli account free. Ecco come si presenta il menu:

Cliccando il pulsante blu si viene indirizzati ad una pagina di CAS (Central Authentication Service) sul dominio exacttarget.com, che è di proprietà di Salesforce naturalmente. Non avendo delle credenziali valide da inserire, non riesco a proseguire nella procedura e quindi non so dire se si tratti in effetti di una nuova feature o se invece si tratti – come ritengo più probabile – di un errore di Google.

L’ultimo annuncio riguardante l’integrazione è infatti risalente a pochi giorni fa ( 7 febbraio, ecco il post ) ma riguarda sempre e solo GA 360: nello specifico il post informa che è possibile trasferire altri “segnali” da Salesforce ad Analytics, oltre allo stato dei lead, ad esempio un campo custom da trasformare in una custom dimension, e che anche le informazioni sulle vendite offline possono essere integrate facilmente dentro GA. Peraltro il post ne segue un altro della settimana prima ( 31 gennaio ) ancora più interessante perché introduce il legame 1:1 tra il clientID di GA e l’Id di Salesforce, ovvero introduce la possibilità di creare audience su Analytics e “spararle” su Salesforce in modo da essere azionabili tramite di esso, anche via email se fanno parte del database.

Entrambi i post tuttavia, come detto, si riferiscono alla versione a pagamento dello strumento, per cui risulta anomalo che gli account free vedano il menu di integrazione. Nelle discussioni che seguo nessuno ha ancora dipanato il mistero, quindi non ci resta che aspettare e vedere se ci sarà un annuncio o piuttosto una correzione… 🙂


Jan 10 2019

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

Piccoli miglioramenti grafici ai grafici

autore: Marco Cilia categoria: generale tag:

I più attenti di voi si saranno sicuramente accorti che Google Analytics ha modificato leggermente i suoi grafici. Bisogna “aguzzare la vista” perché la modifica è lieve (infatti un grigio anche leggermente più marcato non lo avrei disdegnato, ma tant’è), ma è molto utile: nello specifico, l’asse delle ordinate contiene sempre tre valori (0, il mediano e quello arrotondato più alto per contenere il punto con valor massimo da mostrare), ma le linee orizzontali del grafico sono invece disponibili anche per i valori di mezzo di ogni scaglione; cinque linee invece di tre per intenderci. O meglio ancora con una immagine:

Potrebbe sembrare un’inezia, ma in realtà è molto utile quando i dati sono all’incirca piatti, perché aiuta a comprendere meglio le piccole variazioni che sarebbe più difficile cogliere dovendo sempre muovere l’occhio verso una linea più lontana.

Se notate, anche le date sono un po’ cambiate: adesso il mese anno sono scritti per esteso, e intervallati ogni tanto da un giorno, sempre relativo al mese a sinistra. Questo tipo di visualizzazione è automatico, quindi non si può decidere a priori se mostrerà uno, due o più giorni, dipende dal periodo temporale selezionato e da quanto larga è la finestra del vostro browser; se infatti riducete le dimensioni, le date tornano ad avere il formato precedente. Anche questo è un piccolo aiuto visuale che può facilitare le analisi e far risparmiare qualche click.


Nov 14 2018

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

Addio SDK per app mobili e property di tipo “mobile”

autore: Marco Cilia categoria: codice di monitoraggio tag: ,

Questa notte sono iniziate ad arrivare mail di avviso da Google Analytics riguardo a “Cambiamenti importanti alle proprietà di Google Analytics per app per dispositivi mobili”.

Il punto saliente è che tra un anno inizieranno a sparire i report delle property di tipo MOBILE. Se non sapete di che tipo sono le vostre property (perché magari avete un’app ibrida o una web app e non ricordate cosa è stato scelto per tracciarla), dovrete andare nella homepage di Analytics, dove c’è l’elenco delle property/viste cui avete accesso, e controllare le icone a fianco ai nomi delle property.

Se l’icona è a forma di telefonino (frecce rosse nello screenshot qui sopra), allora siete soggetti alle conseguenze indicate nella mail.
Se l’icona è a forma di mondo, o vi è indicato “Firebase”, allora siete a posto.

La parte saliente della mail è questa:

Nel 2019, inizieremo a ritirare le proprietà che ricevono dati esclusivamente da Google Analytics Services SDK.

  • La raccolta e l’elaborazione dei dati relativi a tali proprietà verrà interrotta il 31 ottobre 2019.
  • Fino al 31 gennaio 2020, sarà possibile accedere ai dati storici di queste proprietà attraverso l’interfaccia utente e l’API.
  • Dopo la disattivazione del servizio, non sarà più possibile accedere a queste proprietà tramite l’interfaccia utente o l’API di Google Analytics e i relativi dati saranno rimossi dai server di Google Analytics. In futuro riceverai altre notifiche.

In pratica è meglio se da adesso in poi ogni nuovo progetto, o aggiornamento di progetto, utilizzi Firebase Analytics e non i vecchi SDK; un processo già in atto da tempo, anche se ancora qualcuno che fa la scelta “conservativa” si trova. Ma Google l’ha appena spazzato via con questa mail 🙂


Sep 17 2018

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

Il piano B per rendere il cliente padrone del suo account

autore: Marco Cilia categoria: generale tag: ,

Ancora nell’anno domini 2018 ogni tanto mi imbatto nel caso in cui un cliente, magari non skillatissimo a livello di Analytics, non ha il pieno possesso del suo account Google Analytics: vuoi perché l’agenzia abituata al “lock-in” ha creato una property dentro al suo account (“facciamo sempre così”), vuoi perché chi ha realizzato il sito ha messo Analytics al 90°, sempre partendo dal proprio account (“non sapevo se ne potessero creare altri”), o varie altre versioni più o meno fraudolente volontarie.

Premesso che la configurazione ottimale è sempre e soltanto una: il cliente è ADMIN a livello di ACCOUNT (più MANAGE USERS, naturalmente) del suo o dei suoi account Google Analytics, e le agenzie e i fornitori vengono abilitati di volta in volta per la gestione dei progetti e le necessità. Ma se così non è, tipicamente vi ritroverete nella situazione in cui dovrete chiedere al cliente di chiedere alla vecchia agenzia di abilitarlo come ADMIN + MANAGE USER in modo che lui possa aggiungere voi e farvi iniziare a lavorare. La risposta però potrebbe anche (anzi, è probabile che sia) essere una frase all’incirca simile a “non possiamo. Se vi facciamo ADMIN dell’account, vedreste tutte le property” (sottinteso: vedreste tutti i gonzi che stiamo bloccando nel nostro account e/o gli spending Google Ads).

Se anche vi ricordaste che ormai si possono spostare le property da un account all’altro, sapreste che per farlo è necessario proprio il privilegio di amministratore (edit) e di gestione utenti.

Il piano B prevede che si faccia la procedura al contrario: voi creerete un nuovo account Google Analytics, vuoto e di cui sarete amministratori. Darete accesso pieno all’agenzia, che non vedrà nulla, e fornirete istruzioni affinché sia lei a “spingere” la property nel vostro nuovo account. Fatto quello potrete rimuovere la vecchia agenzia e aggiungere il cliente con pieni poteri. Oppure potrete spostare a vostra volta la property in un account del cliente, consolidando magari situazioni caotiche in cui ci sono diversi GA account con gestioni multiple e disordinate degli utenti.

Sembra una banalità, ma a volte alle soluzioni semplici non ci si pensa 🙂


Sep 12 2018

cosa hanno a che fare il 10 luglio 2012 e il GDPR?

autore: Marco Cilia categoria: codice di monitoraggio

non ne ho la più pallida idea. Però in qualche modo sono collegati. Ora vi spiego:

Se avete avuto modo di andare un po’ indietro con le date dei periodi di analisi dopo l’introduzione del setting di “controllo conservazione dati“, avrete notato che le cose non sono così lineari come ce le aspettavamo: mi riferisco soprattutto a chi ha lasciato 26 mesi (il periodo che veniva proposto come predefinito) come periodo di conservazione preferito.

Se notate i grafici dello screenshot qui sopra, periodo selezionato 12 agosto 2008 – 10 settembre 2018, noterete come il grafico degli utenti si azzeri per le date più vecchie del 23 agosto 2016 circa, e la stessa cosa accade per le metriche sessioni/utente. Le pageview come vedete ci sono tutte. Seguendo il ragionamento del setting del GDPR, le informazioni sui singoli utenti antecedenti al periodo di retention sono perse, quindi il sistema non può calcolare gli utenti unici e le metriche relative alle “unicità”.

La prima cosa interessante è in realtà che se giochiamo un po’ con le date, la cosa non sembra così categorica: se seleziono 12 luglio 2016 – 10 settembre 2018, vedo i dati del 12 luglio; se seleziono 12 giugno 2008 – 10 settembre 2018, i dati di luglio non ci sono più. Sembra quindi esserci una sorta di filtro di visualizzazione più che una cancellazione vera e propria, o almeno la cosa vale per i mesi borderline con il periodo di retention.
La seconda informazione è che abbiamo detto che ci sono 12,4 milioni di pageview, e che esse sono aggregate e quindi “salve”. Bene, allora apro il report “tutte le pagine” e…

all’apparenza il grafico sembra normale, MA il totale delle pagine in testa alla tabella segna 1,1 milioni invece di 12,4. Decisamente male! inoltre l’indicatore giallo mi dice “Alcuni dati di questo rapporto non sono disponibili perché hanno una data precedente al periodo di conservazione dei tuoi dati.” Ora, potreste scommettere che i dati che mancano a questo report sono quelli più vecchi del 23 agosto 2016, come per il primo grafico… ma perdereste. Infatti un report delle pagine con data 30 luglio 2014 – 10 settembre 2018 ha lo scudetto verde (no campionamento o mancanza di dati) e il numero corretto di pageviews. Anche un report 15 marzo 2013 – 10 settembre 2018 va bene. Anche un report 11 luglio 2012 – 10 settembre 2018 è perfetto e completo con le sue 5.469.365 pageviews.
Invece un report 10 luglio 2012 – 10 settembre 2018 ritorna ad avere lo scudetto giallo, e 1,1 milioni di pagine. Cioè aggiungendo un giorno di report, le pagine scendono di 4,3 milioni.

Ora, se vi state chiedendo PERCHE’ accada, beh non lo so. Ma siccome questa cosa l’ho scoperta qualche settimana fa, posso dirvi cosa so:

  • il 10 luglio 2012 non è una data “rolling”, cioè non si sposta in avanti man mano che passano i giorni. Sembra una data fissa
  • il problema affligge solo – per quanto ho potuto constatare – le property che hanno (o avevano) impostato un periodo di data retention di 26 mesi (potrebbe essere vero per altre retention, ma non ho profili su cui verificare). Se avete selezionato “non scadono mai” dovreste essere immuni
  • si tratta anche qui quasi certamente di un filtro di visualizzazione, ancorché completamente scorrelato temporalmente e apparentemente nella logica dall’impianto del GDPR

Per verificare l’ipotesi che la cosa fosse legata ai dati dei singoli utenti ho costruito un custom report che mimasse il report “tutte le pagine” escludendo le metriche relative alle “unicità”, quindi lasciando solo dimensione PAGINA e metriche PAGEVIEWS, TEMPO MEDIO SULLA PAGINA e ACCESSI. Ebbene, per QUALSIASI range temporale, i dati NON SONO MAI ALTERATI. Ecco la prova sull’arco temporale di partenza:

Insomma, un mistero intricato ma con una soluzione tampone.
A proposito, se volete importare il custom report, ecco il link: https://analytics.google.com/analytics/web/template?uid=VoaUicraRhe2xe3VfelJOA
Se avete idee, parliamone nei commenti!


Jul 10 2018

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

In arrivo il vero report cross device

autore: Marco Cilia categoria: generale tag: , ,

Oggi durante il Google Marketing Live 2018 Google ha annunciato che Analytics presto sarà fornito di report cross-device.
Sento già levarsi le voci e vedo i nasi storti in chi sta per dirmi “hai preso una botta in testa? Google Analytics HA GIA’ i report cross-device, basta passare uno USERID uguale tra desktop e mobile, ed è fatta”.

Si, lo so, ma quella è una funzione “volontaria”, sta al webmaster o a chi implementa i tracker far si che la magia accada. Google oggi ha annunciato una cosa che mi sono sentito chiedere in almeno la metà dei corsi che ho tenuto negli ultimi dieci anni, ovvero il fatto che il ricongiungimento dei dati verrà fatto direttamente dalla piattaforma sulla base dei segnali che normalmente usa per identificare gli utenti su più dispositivi, il più semplice da immaginare e capire è l’essere loggati ad un google account (gmail, youtube, eccetera…)

Ho visto questi report quasi un anno fa a San Francisco, spero che abbiano fatto che passi in avanti perché seppur stupendevoli e sicuramente utilissimi, gli ingegneri non erano ancora riusciti a fugare un paio di dubbi che i clienti più avanzati ed esigenti vorrebbero risolti da una funzionalità come questa, guarda caso sempre legata a iOS e Safari 😀

In ogni caso preparatevi, perché se funzionerà a dovere e con una significatività statistica decente, questo cambierà completamente le vostre attuali valutazioni dei ritorni di marketing!

Che ne pensate?


May 23 2018

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo giallo - articolo avanzato

Arriva la cancellazione dei dati del singolo utente

autore: Marco Cilia categoria: API tag: ,

Quasi al fotofinish, il GDPR entra in vigore tra due giorni, Google rilascia la User Deletion API che come si intuisce dal nome è la funzione per cancellare i dati dalla piattaforma i dati puntuali di un singolo utente, dove “utente” sta per clientID, userID o identificativo dell’utente dentro a una app.

L’API prende come input sostanzialmente tre parametri: il tipo di identificativo che stiamo passando (appunto, se si tratta di un client/user ID o di un’app), l’identificativo stesso e la property (web o Firebase) dove cancellare i dati.
Esiste poi un ulteriore parametro che però sinceramente non ho compreso bene: si tratta del DeletionRequestTime, che dovrebbe indicare una data fino a quando cancellare i dati; io non ho capito se si intende “da oggi indietro e fino a…” oppure “dall’inizio dei dati e in avanti fino a…”, anche se propenderei per la prima ipotesi.

Il fatto che sia stata rilasciata un’API da un lato è sensato, perché si può automatizzare facilmente il lavoro, dall’altro rende difficile cancellare un singolo utente per chi non è affine al mondo delle interfacce programmatiche. In ogni caso secondo me basterà aspettare un pochino e si vedranno fiorire servizi basati su questa API. So per certo che l’autore del package di R “GoogleAnalyticsR” ha già implementato la feature e la sta testando, per cui se siete soliti utilizzare quel package è solo questione di tempo…


Apr 12 2018

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

Clamoroso! Grazie al GDPR potrete cancellare dati da GA

autore: Marco Cilia categoria: generale tag: , ,

Spesso su questo blog vi ho raccontato che mi pregio di essere un utente “della prima ora” di Google Analytics, ovvero di essermi iscritto e di avere un profilo con dati dal giorno 1 della sua esistenza, il 14 novembre 2005. Da allora, Google non ha mai cancellato niente, nonostante su alcune versioni del contratto di servizio avesse il diritto di farlo per i dati più vecchi di 36 mesi (ora mi sembra questa dicitura sia scomparsa).

Oggi invece gli utenti di Google Analytics hanno ricevuto l’ennesima email di aggiornamento sugli adempimenti che Google sta portando avanti per adeguarsi al nuovo regolamento europeo sulla protezione dei dati (o in breve GDPR), che entra in vigore il prossimo 25 maggio: il contenuto della mail è clamoroso perché per la prima volta nella storia di questo strumento introduce una nuova opzione nel pannello di controllo che permette di cancellare *alcuni* dati più vecchi di una certa data, rolling di mese in mese. L’avviso è riportato anche accedendo all’interfaccia di Google Analytics.

Quali dati si potranno cancellare? tutti quelli legati a un cookie, un identificativo utente (userID) o un identificativo advertiser (Doubleclick cookie, identificativi dei device) o un evento. I dati aggregati invece non saranno cancellabili, il che significa probabilmente che il numero di sessioni non si azzererà mai, mentre il numero di utenti (basato sul conteggio dei cookie unici) potrebbe. Le sorgenti di traffico, quando viste per numero di sessioni, dovrebbero essere un report che non cambia mai, il report degli eventi potrebbe variare. E così via…

Il nuovo setting lo potete trovare se avete privilegi di MODIFICA su una property, andando nelle impostazioni della property, nella sezione Informazioni sul tracking e poi Data Retention.

Come vedete le opzioni disponibili sono da uno a cinque anni + due mesi fissi, oppure disabilitato. ATTENZIONE PERCHE’ DI DEFAULT IL SETTING E’ IMPOSTATO SU 26 MESI

La cancellazione dei dati viene fatta una volta al mese in base al setting che viene scelto. La scelta può essere annullata entro 24 ore, quindi se adesso modifico l’opzione ho tempo fino a domani alla stessa ora per annullare. Dopodiché GA prenderà atto della nuova scelta e alla prossima cancellazione opererà di conseguenza.
L’altra opzione disponibile permette di calcolare il lasso di tempo sulla base dell’ultimo evento inviato da un identificativo. Ovvero se dico che il mio periodo di retention è 14 mesi ma imposto su ON l’opzione “Reimposta in caso di nuova attività”, allora se l’utente visita il sito ogni mese non verrà cancellato mai, se invece non visita per 14 mesi verrà cancellato.

Quindi meglio ripetere il concetto: se lasciate tutto così com’è, a partire da Giugno Google Analytics cancellerà ALCUNI dati associati a cookie che non si sono presentati sul sito per 26 mesi
Non confondete questa cosa con il fatto che di default se un utente non torna per 24 mesi, GA lo considera nuovo utente alla prossima visita. Qui si sta parlando di MODIFICHE ai dati di due anni fa.

Ma c’è una seconda novità, sempre preannunciata dalla mail. Tra poco Google introdurrà uno strumento per cancellare PUNTUALMENTE i dati di un utente, basandosi sul clientID standard del cookie di Google Analytics, su uno userID o su un identificativo app se si usa Firebase. Questo potrebbe anche significare poter cancellare le proprie sessioni e transazioni di test su un ecommerce, tra l’altro.

Che dire, si tratta di un cambiamento epocale per come siamo abituati a pensare al prodotto e alle sue caratteristiche più intrinseche: il famoso detto “i report vecchi non cambiano mai” non sarà più del tutto vero, e finalmente quando un cliente dirà “ho rifatto a distanza di mesi lo stesso esatto report e i risultati sono diversi” avremo qualcosa a cui pensare davvero, invece di liquidarlo perché sappiamo (sapevamo, tra poco) che non è possibile…


Mar 01 2018

Finalmente i gruppi negli utenti di GA!

autore: Marco Cilia categoria: codice di monitoraggio

Il blog di Google Analytics ci informa con un post che una delle feature più attese da SEMPRE, almeno per gli utenti di livello medio ed enterprise, è giunta nei nostri account: i gruppi di utenti.

Innanzitutto i gruppi di utenti si possono creare soltanto dentro a un’ORGANIZATION, ovvero un’entità superiore all’account Analytics che può essere creata partendo dal link 360suite.google.com. Se siete organization admin o user admin di una organization, cliccando il “+” nell’interfaccia di creazione utenti dell’organization potete scegliere se creare (aggiungere) un singolo user o un gruppo, e in questo secondo caso dovrete dare un nome al gruppo e aggiungere i singoli indirizzi email. Più sotto potrete dare accesso al gruppo ai singoli prodotti linkati in quella organization, con un controllo abbastanza capillare. Ad esempio invece di aggiungere 10 utenti a 4 account Analytics, un Tag Manager e un Optimize, si può creare un gruppo, e poi dare accesso a questo gruppo, risparmiandosi innumerevoli decine di clic.

Inoltre, per i casi più complessi, c’è una feature potente ma da maneggiare con cautela: dentro ai gruppi si possono aggiungere altri gruppi! Maneggiare con prudenza 🙂

La cosa potrebbe dall’altro verso complicare un pochino gli assessment degli utenti, perché i gruppi nell’interfaccia degli utenti dei prodotti, ad esempio Analytics, compaiono come gruppi e non come singoli account email. Ergo non c’è modo di conoscere lo status degli accessi degli appartenenti ad un gruppo senza essere anche un Organization admin, mentre oggi con il giusto privilegio l’elenco degli utenti è sempre visibile nella sua interezza. E’ una cosa che secondo me andrebbe migliorata, L’interfaccia dovrebbe mostrare i singoli account e semmai a quale gruppo appartengono, oppure permettere un livello di drill-down dal gruppo ai suoi componenti. Può darsi che in futuro sarà possibile.

L’altra novità che il post ci segnala è l’applicazione più restrittiva delle regole di abilitazione utenti: le regole di abilitazione dettano i criteri affinché un utente possa o non possa essere aggiunto ai prodotti della suite Google (sia free sia a pagamento), ma se fino a ieri l’infrazione della regola provocava solo una notifica (del tipo “ecco l’elenco degli utenti che non soddisfano la tua regola”), da oggi è possibile far si che le norme siano restrittive e bloccanti!

Quindi io in qualità di Organization Admin potrei dire che si possono abilitare solo account che contengono @dominiocliente.it e @dominioagenzia.com e se qualcuno provasse ad aggiungere una gmail riceverebbe un errore e non potrebbe farlo. Esattamente come in questa immagine esplicativa

Un deciso passo avanti verso uno standard di prodotto di livello enterprise, anche se in realtà si applica anche alla versione free, che renderà molto più semplice la gestione degli utenti, in special modo nella big corporation, dove si sono sempre fatti i salti mortali per tenere tutto allineato sotto questo punto di vista.


Jan 23 2018

HelpSemaforoQuesto semaforo indica il livello difficoltà del post
semaforo verde - articolo per tutti

Ecco la prima integrazione GA360 – Salesforce

autore: Marco Cilia categoria: ga-premium tag: ,

Una delle situazioni più comuni con cui mi trovo ad avere a che fare in ambito GA360 è la presenza in azienda di Salesforce, in una o più delle sue incarnazioni. La cosa non deve essere affatto isolata, tanto è vero che qualche mese fa Google e Salesforce hanno annunciato una partnership per integrare più a fondo le loro piattaforme.
Pensandoci la cosa ha perfettamente senso: da un lato GA contiene tutto lo scibile sul marketing online di un brand, i tracking, i risultati, gli spending e i ROI, la storia degli utenti e la capacità di segmentazione. Ma spesso, specialmente nel caso di siti di lead generation, si ferma al potenziale contatto.
Salesforce, d’altro canto, è una potenza incredibile per quanto riguarda tutto quel che avviene “dopo”: CRM, marketing cloud, marketing automation, ecc ma sa poco o nulla di quanto è accaduto prima del lead.

Esistevano già dei metodi “caserecci” per provare a fare questa integrazione, ma erano tutti basati su presupposti che non ho mai trovato perfettamente sensati. Come tutte le forzature, non è detto che il risultato fosse quello atteso o sperato.

Da qualche giorno invece l’integrazione tra Salesforce Sales Cloud e GA360 è realtà, e permette di importare dentro a Google Analytics le informazioni riguardanti i “cambi di stato” di un lead, per tutta la sua storia offline. Ogni cambio di stato viene sparato verso GA con un evento, che viene legato all’utente e al lead poiché la form di Salesforce invia anche l’identificativo del cookie di Analytics, e questi eventi possono poi essere usati per creare dei goal in grado di dare una visione qualitativa dei lead. Ad esempio si potrà capire che un dato canale porta molti lead, ma che si fermano quasi tutti al primo step della pipeline, mentre altri canali magari ne portano meno, ma poi vengono chiusi quasi tutti offline.

Come detto, Salesforce importerà questi cambi di stato come eventi, che avranno categoria “Lead” o “Opportunity” (a seconda che provengano da form del modulo Lead o form del modulo Opportunity, ovviamente), action “New” oppure “Change” e label variabile a seconda della vostra implementazione e definizione degli status all’interno di Salesforce Cloud. Nessun nuovo report, quindi, ma un sacco di informazioni utili per le analisi, le segmentazioni, il remarketing (si può creare una lista di remarketing di tutti i clientID che sono passati in un certo status, e pusharla immediatamente su AdWords o Doubleclick). Possibilità interessantissime a portata di click 🙂