Protocollo di A/B testing per il pricing

Protocollo di A/B testing per il pricing












Home » Risorse » Qui

Non c'è ottimizzazione senza misurazione, e l'ottimizzazione dei prezzi non fa eccezione, poiché richiede esperimenti e misurazioni. Troppo spesso il pricing si riduce a modificare i prezzi, senza che queste modifiche vengano sfruttate per capire come il mercato reagisce a nuovi prezzi. Le strategie di pricing dovrebbero essere elaborate sulla base di conoscenze precise, di analisi a posteriori delle modifiche dei prezzi, finalizzate all'affinamento delle strategie già in uso. In questa pagina ti proponiamo un protocollo di A/B testing, pensato appositamente per il pricing, da usare con il supporto di Lokad. La discussione verterà soprattutto sugli strumenti Lokad, ma, poiché il protocollo non è specifico, può essere usato anche con altri strumenti, compreso Excel (a patto però che i dati siano molto accurati).


1. Creare un documento di riferimento

Se sei in grado di eseguire un esperimento di pricing, presto avrai dozzine e dozzine di esperimenti. Senza un metodo strutturato per raccogliere tutte queste informazioni, avrai una gran quantità di risultati confusi, inutilizzabili per un qualsiasi tipo di analisi. Ti suggeriamo, quindi, di cominciare ogni esperimento con la creazione di un documento di riferimento in cui riunire tutte le informazioni relative all'esperimento. Puoi creare il documento con Microsoft Word o, ancora meglio, con uno strumento collaborativo online come Google Sites o hackpad, o un altro dei CMS disponibili online.

Una volta creato il documento, dovrai trovare un nome facile da ricordare per l'esperimento: infatti, un esperimento può ritenersi efficace solo se è facile parlarne e scambiare conclusioni in proposito, considerando anche che le persone che dovranno occuparsene potrebbero avvicendarsi nel tempo. Ricorda anche che la noia è il nemico numero uno della conoscenza: se il nome è troppo noioso, l'esperimento ha buone probabilità di essere tralasciato anche dagli impiegati più zelanti.

2. Creare un progetto specifico

Ti suggeriamo di creare un progetto dedicato all'esperimento all'interno del tuo account Lokad. Per maggiore chiarezza, è meglio assegnare al progetto lo stesso nome dell'esperimento. Ti consigliamo anche di sfruttare la funzionalità hyperlink della casella label per inserire un link al documento di riferimento disponibile online. Il tuo script Envision dovrebbe quindi cominciare così:

// Esperimento di pricing: Sevilla
// Inizio: 2014-07-09 Fine: 2014-08-08
// Autore: Joannes Vermorel
show label "http://example.org/my-reference-document Ref. Document"

La casella label appare nel pannello di controllo come un hyperlink al documento di riferimento che contiene tutti i dettagli dell'esperimento.

Il progetto servirà, nel corso dell'esperimento, a:

  1. Creare gruppi di articoli che fungeranno da gruppi di controllo
  2. Mantenere i gruppi di controllo inalterati
  3. Definire la nuova strategia di pricing
  4. Controllare che i prezzi vengano applicati correttamente
  5. Compilare i risultati dei due gruppi di controllo

A ognuna di queste fasi corrisponderà una sezione di script nel progetto.

3. Definire l'ipotesi da testare

Quando si testa una strategia di pricing, si tende a rispiegare i risultati alla fine del test, che questi confermino le ipotesi iniziali oppure no. Si tratta di una trappola psicologica, la cosiddetta fallacia narrativa descritta da Taleb:

La fallacia narrativa si riferisce alla nostra limitata capacità di guardare a una serie di eventi senza attribuirvi una spiegazione, o senza forzare un legame logico, una correlazione tra essi. Le spiegazioni uniscono i fatti. Li rendono più facili da ricordare. Aiutano a dare loro un senso. Questa propensione può rivelarsi sbagliata quando rafforza in noi l'impressione di aver capito. —Nassim Nicholas Taleb, Il Cigno Nero (traduzione nostra)

Il problema si ripresenta anche nel pricing, poiché le condizioni di mercato non offrono un ambiente controllato. Non importa quanta cura mettiamo nel protocollo: molti fattori rimarranno comunque fuori dal nostro controllo, in primis le strategie dei nostri competitor.

Per tutti questi motivi, è importante definire fin da subito l'ipotesi da testare, per essere sicuri che il test serva a confermare o meno l'ipotesi iniziale, non una tesi messa insieme ad hoc nel corso dell'esperimento. L'ipotesi va scritta all'inizio del documento di riferimento di cui abbiamo parlato prima. Un esempio di ipotesi è: Un calo significativo nel volume delle vendite è determinato non da un calo della domanda, ma da competitor meno visibili con una politica di prezzo aggressiva. Se dunque riducessimo considerevolmente i nostri margini sui prodotti interessati, dovremmo osservare un conseguente aumento dei volumi di vendita.

4. Gruppi di controllo positivi e negativi

Una volta definita l'ipotesi, possiamo delineare il test in sé. Spesso è impossibile, o comunque poco pratico (a volte addirittura illegale), cercare di sottoporre due prezzi diversi per uno stesso articolo a due gruppi di consumatori diversi. Un approccio più pratico consiste nel selezionare due gruppi di articoli equivalenti, che rappresentino solo una piccola parte del catalogo.

I due campioni saranno rispettivamente:
  • il gruppo di controllo positivo, a cui verrà applicata la nuova strategia di pricing;
  • il gruppo di controllo negativo, che manterrà la vecchia strategia di pricing.

Confrontando i risultati del gruppo positivo e di quello negativo possiamo stabilire se l'ipotesi iniziale era corretta. Con Envision è molto semplice selezionare due gruppi di controllo a caso, grazie alla funzione hash:

seed := "hello world"
R = rankd(hash(concat(Id, seed)))
where R <= 1000
  // qui gruppo positivo
where R > 1000 & R <= 2000
  // qui gruppo negativo
Nello script qui sopra, calcoliamo una serie casuale di articoli alla riga 2. La funzione hash produce un numero pseudo-casuale per la stringa passata come input. Sottolineiamo pseudo-casuale, perché la stringa restituisce ogni volta lo stesso valore hash. Per avere campioni distinti, bisogna modificare il testo passato come seed. Alla riga 3, selezioniamo 1.000 articoli per il gruppo di controllo positivo. Alla riga 5, procediamo allo stesso modo per il gruppo negativo.

Possiamo applicare questa stessa logica, con le dovute modifiche, anche alle situazioni in cui vogliamo definire due gruppi che rispondano entrambi alle stesse condizioni. Ad esempio, supponiamo di voler stabilire gruppi di controllo con gli articoli del brand Fabrikam. Possiamo fare così:
where Brand == "Fabrikam" // ci concentriamo solo sul brand 'Fabrikam'
  seed := "hello world"
  R = rankd(hash(concat(Id, seed)))
  where R <= 50
    // qui gruppo positivo
  where R > 50 & R <= 100
    // qui gruppo negativo

5. Salvare i gruppi di controllo

Se selezioniamo i gruppi di controllo sulla base di condizioni complesse, rischiamo di ottenere ogni volta una lista di articoli diversa. Se ad esempio introduciamo nuovi articoli, questi influiranno sulla logica di selezione. Ti consigliamo quindi di salvare i gruppi di controllo in un file a parte, in modo da evitare cambiamenti inattesi.

seed := "hello world"
R = rankd(hash(concat(Id, seed)))
Control = ""
where R <= 1000
  Control = "pos" // gruppo positivo
where R > 1000 & R <= 2000
  Control = "neg" // gruppo negativo

// esportiamo il gruppo
startDate := "2014-07-09"
endDate := "2014-08-09"
where Control != ""
  show table "sample" export:"/exp/g-sevilla.tsv" with
    Id
    startDate as "Date"
    endDate, Control
    Price

Nello script qui sopra, una volta stabiliti i gruppi, salviamo i risultati nel file `g-sevilla.tsv`. Più avanti vedremo come il prefisso `g` (o un qualsiasi altro prefisso) può evitare sovrapposizioni tra i campioni. `sevilla` è il nome che abbiamo scelto per il nostro esperimento. Il file è già formattato per poter essere caricato nuovamente su Lokad. Esegui la logica una volta, poi commenta ed escludi le righe dedicate all'esportazione del file, per evitare di sovrascrivere un file già esistente. Per maggiore sicurezza, scarica il file e salvane una copia allegandola al documento di riferimento.

Per evitare che i gruppi si sovrappongano a quelli di un altro esperimento, puoi caricare di nuovo il file salvato e usare le informazioni che contiene per escludere gli articoli più rilevanti, in questo modo:
read "/exp/g-*" as Experiments // carichiamo tutti gli esperimenti

today := Date(2014,7,9)
IsPartOfGroup = false
where Experiments.EndDate < today // escludiamo gli esperimenti in corso
  // cerchiamo un gruppo che che combaci con il nostro
  IsPartOfGroup = exists(Experiments.Date) 

where not IsPartOfGroup
  seed := "hello world"
  R = rankd(hash(concat(Id, seed)))
  Control = ""
  where R <= 1000
    // qui gruppo positivo
  where R > 1000 & R <= 2000
    // qui gruppo negativo

6. Definire lo script per il nuovo pricing

Finora abbiamo considerato più strategie di pricing. Vediamo ora come implementare lo script per una nuova strategia di pricing. Non entreremo qui nei dettagli della logica di pricing; ti basti sapere che i prezzi possono essere esportati tramite una semplice casella table:
read "/exp/g-sevilla.tsv" as Scope

// La logica originale per la creazione dei gruppi di controllo è spiegata.
// Ricarichiamo i gruppi di controllo direttamente dalla copia salvata.
Control = last(Scope.Control) or ""

where Control != "" // escludiamo gli elementi che non ci interessano
  // tagliato: logica di pricing effettiva
  show table "sample" export:"/exp/p-sevilla.tsv" with Id, today() as Date, Price
In questo script carichiamo prima di tutto la copia dei gruppi di controllo. Poi, restringiamo il campo d'azione ai soli gruppi di controllo. Infine, esportiamo il file con i nuovi prezzi.

Nella pratica, mantenere inalterati i nuovi prezzi potrebbe rivelarsi più complicato che mantenere inalterati i gruppi di controllo. I prezzi, infatti, cambiano continuamente, per tutta la durata dell'esperimento, a seconda delle strategie adottate.

7. Pubblicazione e osservazione dei prezzi

Una volta creato lo script per produrre i nuovi prezzi, dobbiamo pubblicare i prezzi su tutti i canali di vendita. Se possibile, è meglio fare affidamento sui metodi di pubblicazione dei prezzi almeno in parte automatizzati. Lokad mette a tua disposizione una API REST, che avvia automaticamente i progetti. Una volta eseguito lo script, potrai recuperare i file di output da Lokad tramite FTP o FTPS e importarli nei sistemi di produzione.

Per essere sicuri che le osservazioni sulle vendite successive alla modifica dei prezzi siano corrette, è di vitale importanza assicurarsi che i prezzi sui vari canali di vendita siano quelli prodotti dallo script Envision. Capita spesso che i prezzi non vengano importati correttamente, o che vengano importati solo parzialmente, generando così una discrepanza tra i prezzi pubblicati e i prezzi calcolati con una precisa strategia di pricing.

In teoria, i prezzi storici pubblicati andrebbero reinseriti in Lokad come dati di input. In questo modo, sarebbe possibile confrontare prezzi pubblicati e prezzi calcolati con Lokad, per verificare che i valori coincidano. Nello script qui sotto, carichiamo prima i prezzi storici recuperati dalla produzione, poi il raggio d'azione dell'esperimento e i prezzi originariamente calcolati.

//  ... elementi selezionati e altri file di dati ...
read "/prices.tsv" as Prices // dai sistemi di produzione
read "/exp/g-sevilla.tsv" as Scope
read "/exp/p-sevilla.tsv" as ExpPrices

// La logica originale per la creazione dei gruppi di controllo è spiegata.
// Ricarichiamo i gruppi di controllo direttamente dalla copia salvata.
Control = last(Scope.Control) or ""

where Control != "" // escludiamo gli elementi che non ci interessano
  // data per la pubblicazione dei prezzi
  when date <= date(2014,8,1) 
    where last(Prices.Price) != last(ExpPrices.Price)
      show table "Item count with price mismatch" with count(Id) 
Lo script indica il numero di casi in cui il prezzo recuperato dai sistemi di produzione non corrisponde a quello calcolato in origine dallo script di pricing.

Dopo qualche giorno (o qualche settimana, a seconda del periodo applicabile all'esperimento), potremo esaminare le osservazioni raccolte sull'evoluzione delle vendite per i due gruppi, per stabilire se l'ipotesi iniziale era corretta o meno. Accumulare esperimenti conclusivi è un vantaggio notevole per un commerciante, poiché questi consentono di definire strategie di pricing sempre più efficaci.