Onur Alp Soner, CEO e co-fondatore di Countly – Serie di interviste

Onur Alp Soner è il co-fondatore e CEO di Countly, una piattaforma di analisi digitale e di coinvolgimento in-app. Tecnologo e imprenditore, ha fondato Countly partendo da zero per dare alle aziende più controllo su come comprendere e interagire con i propri utenti. Sotto la sua guida, Countly è cresciuta in una piattaforma affidabile per le aziende di tutto il mondo che desiderano innovare rapidamente mantenendo la privacy degli utenti al centro delle loro strategie di crescita

Riportaci al momento che ti ha portato a fondare Countly — cosa stavi incontrando con gli strumenti di analisi esistenti che ti ha convinto che il modello di proprietà dei dati era fondamentalmente rotto?

Circa 13 anni fa, quando le app mobili stavano iniziando a decollare, gli strumenti di analisi disponibili seguivano un modello molto particolare. Molti di loro erano gratuiti o relativamente economici, ma il compromesso era che la piattaforma raccoglieva e monetizzava i tuoi dati, spesso alimentando ecosistemi pubblicitari. All’epoca, questo era ampiamente accettato come il modo normale in cui funzionavano le cose.

Questo, tuttavia, non ci sembrava giusto. Anche come piccola azienda, l’idea di consegnare tutti i nostri dati utente solo per capire come si stava eseguendo il nostro prodotto non aveva senso.

Countly è iniziata come risposta a questo. Volevamo costruire analisi che le aziende potessero possedere e controllare completamente, ed è per questo che l’abbiamo lanciata come piattaforma open-source e self-hosted. L’idea era semplice: le organizzazioni dovrebbero essere in grado di comprendere e agire sui propri dati senza darli via. Questo principio è ancora al cuore di Countly oggi.

Dal momento in cui hai fondato Countly, l’IA ha spinto la proprietà dei dati da una preoccupazione di nicchia a un requisito strategico. Quando ti è diventato chiaro che questo principio avrebbe avuto importanza ben al di là dell’analisi?

Negli anni precedenti, la maggior parte delle conversazioni sulla proprietà dei dati erano inquadrate attraverso la privacy o la conformità. Era principalmente il settore bancario, i fornitori di servizi sanitari e i governi che si preoccupavano profondamente di dove risiedessero i loro dati e chi li controllasse. Per molti altri, l’analisi era ancora vista come uno strumento di reporting semplice, quindi la questione della proprietà non sembrava urgente.

Questa prospettiva ha iniziato a cambiare quando le aziende hanno iniziato a fare affidamento maggiormente sui dati per gestire i propri prodotti, non solo per misurarli. Una volta che l’analisi si è spostata dal reporting alla presa di decisioni, alimentando la personalizzazione, i cambiamenti dei prodotti e il coinvolgimento dei clienti, l’importanza del controllo di quei dati è diventata molto più chiara. Ogni azienda digitale, dalla mobilità all’ospitalità, ha iniziato a competere sui dati, non solo sull’esperienza front-end.

L’IA ha accelerato drasticamente quella consapevolezza. Puoi acquisire o costruire un modello di IA, ma non puoi comprare i dati comportamentali che riflettono come i tuoi clienti interagiscono con il tuo prodotto. Quei dati sono unici per ogni organizzazione.

Molte organizzazioni credono di essere “pronte per l’IA” perché hanno grandi volumi di dati. Da ciò che vedi all’interno di aziende reali, cosa manca solitamente sotto la superficie?

La mancanza di dati non è solitamente il problema. Il vero problema è la mancanza di dati utilizzabili. Molte organizzazioni hanno enormi volumi di informazioni, ma sono frammentate attraverso diversi strumenti, team e sistemi. Ad esempio, il marketing potrebbe avere un set di dati, il prodotto un altro e l’ingegneria la sua stessa telemetria, spesso archiviata in formati diversi con poca struttura condivisa.

Perché l’IA sia utile, i dati sottostanti devono essere puliti, coerenti e contestualizzati. Non è sufficiente raccogliere eventi o log; è necessario capire cosa quei segnali rappresentano effettivamente. Senza quel livello semantico, i sistemi di IA stanno essenzialmente indovinando.

Un altro problema è la proprietà. Un numero sorprendente di aziende non controlla effettivamente i propri dati perché risiedono all’interno di piattaforme di terze parti. Ciò rende difficile combinare set di dati, applicare regole di governance o applicare in modo sicuro modelli di IA ad essi.

Quindi, quando le aziende dicono di essere pronte per l’IA perché hanno molti dati, la vera domanda è se hanno una solida base di dati.

Perché i dati di prima parte creano un vantaggio competitivo duraturo nei sistemi di IA mentre i modelli stessi diventano sempre più interscambiabili?

Ciò che crea un vantaggio duraturo non è il modello in sé, ma la comprensione degli utenti che deriva dai dati di prima parte. Quei dati riflettono come le persone interagiscono effettivamente con il tuo prodotto e sono unici per ogni organizzazione. I modelli, d’altra parte, stanno diventando sempre più beni comuni. Puoi acquisirli, adattarli, o passare tra i fornitori relativamente facilmente. Ciò che non puoi replicare è il dato comportamentale generato dai tuoi utenti che interagiscono con i tuoi prodotti nel tempo.

Quei dati catturano modelli, contesto e segnali che riflettono come i clienti si comportano effettivamente. Quando sono strutturati e compresi correttamente, consentono alle aziende di costruire sistemi che imparano continuamente dall’uso reale piuttosto che da set di dati generici.

Dove si rompono silenziosamente le moderne pile di analisi quando vengono riutilizzate per sistemi di IA invece che per reporting, dashboard e KPI?

Tendono a rompersi nel punto in cui i dati devono passare dall’osservazione all’azione. Le pile di analisi tradizionali erano progettate principalmente per il reporting. Raccolgono e aggregano i dati, poi li presentano in dashboard che aiutano i team a capire cosa è successo ieri o la settimana scorsa.

I sistemi di IA, tuttavia, operano in modo molto diverso. Richiedono dati che sono strutturati, contestualizzati e disponibili in tempo reale in modo che possano influenzare direttamente il comportamento di un sistema. Quando le pipeline di analisi sono costruite intorno all’elaborazione batch e al reporting ritardato, lottano per supportare sistemi che devono reagire istantaneamente.

Come si manifesta operativamente la mancanza di vera proprietà dei dati quando i team cercano di spostare l’IA dall’esperimentazione alla produzione?

Di solito si presenta come un problema di controllo. In ultima analisi, se non hai il controllo dei tuoi dati, non hai il controllo della tua IA. Ciò diventa particolarmente chiaro quando i team passano dall’esperimentazione alla produzione. Durante l’esperimentazione, i team possono spesso lavorare con piccoli set di dati o pipeline temporanee, ma i sistemi di produzione richiedono un accesso costante a dati affidabili in tutta l’organizzazione.

Poi, in molte aziende, i dati sottostanti risiedono in diverse piattaforme di terze parti, come strumenti di analisi, sistemi di marketing o servizi cloud. Ciò rende difficile combinare set di dati, applicare regole di governance o spostare dati tra sistemi in modo controllato. Questo è uno dei motivi per cui molti progetti di IA rimangono bloccati in fasi di pilotaggio. Senza dati strutturati e di proprietà dell’organizzazione, diventa difficile distribuire l’IA in modo affidabile in produzione.

Diventa anche più difficile tracciare come un modello ha raggiunto una decisione o ricostruire lo stato esatto dei dati dietro di esso. Senza quel livello di controllo, correggere errori o annullare decisioni diventa estremamente difficile.

Perché una cattiva struttura dei dati, la semantica e il contesto minano anche i modelli di IA più capaci?

Even i modelli di IA più capaci sono solo buoni quanto i dati che ricevono. Se i dati sottostanti sono mal strutturati o mancano di contesto, il modello ha molto poco understanding di cosa quei segnali rappresentino effettivamente.

In molti sistemi, i dati vengono raccolti come eventi isolati o log senza un significato chiaro ad essi associato. Un modello potrebbe vedere migliaia di interazioni, ma senza una struttura e una semantica adeguate, non può distinguere tra ciò che è importante e ciò che è semplicemente rumore.

Il contesto è altrettanto importante. I sistemi di IA devono comprendere come diversi pezzi di dati si relazionano tra loro nel tempo. Senza quel contesto, i modelli possono ancora produrre output, ma sono spesso inaffidabili perché il sistema sta lavorando con informazioni incomplete.

Quali segnali di allarme indicano che un’azienda sta andando verso risultati generici di IA molto prima che quelle esperienze si sentano generiche ai clienti?

Il segnale di allarme più basilare è quando le aziende si affidano agli stessi modelli di IA e strumenti esterni ma fanno molto poco per sviluppare le proprie fondamenta di dati. Se le organizzazioni stanno utilizzando gli stessi modelli ma non li stanno alimentando con i propri dati utente e contestuali, i sistemi stanno essenzialmente lavorando con gli stessi input generici. In quella situazione, l’IA può produrre solo risultati di alto livello o generici. Nel tempo, ciò porta a prodotti che si sentono sempre più simili perché l’intelligenza dietro di essi è costruita sugli stessi limitati dati.

Un altro segnale di allarme è quando le organizzazioni si concentrano fortemente sull’adozione di modelli di IA ma prestano poca attenzione alla struttura e alla qualità dei loro dati. L’IA amplifica ciò che riceve. Se i dati sottostanti sono disordinati, frammentati o mal strutturati, il sistema produrrà semplicemente una versione più sofisticata dello stesso problema.

Per le organizzazioni che cercano di costruire l’IA sui propri dati, cosa consente effettivamente Countly che le piattaforme di analisi e dati tradizionali non fanno?

La chiave è come il controllo sia integrato nella piattaforma. In molti prodotti di analisi, la proprietà dei dati è qualcosa che appare come un’opzione o una funzionalità. Con Countly, siede al cuore del sistema. La piattaforma è stata progettata in modo che le organizzazioni non debbano scambiare il controllo dei propri dati per funzionalità avanzate.

Nella pratica, ciò significa che le aziende possono eseguire Countly nel proprio ambiente, mantenere il pieno controllo del proprio stack di dati e ancora accedere alle funzionalità di analisi, coinvolgimento e automazione su larga scala. Ciò diventa particolarmente importante quando le organizzazioni desiderano costruire l’IA sui propri dati. Molti strumenti di analisi tradizionali sono costruiti principalmente per il reporting, il che significa che i dati che raccolgono spesso rimangono all’interno di dashboard di terze parti invece di diventare una base di dati utilizzabile per altri sistemi. Countly adotta un approccio diverso trattando l’analisi come parte della infrastruttura di dati sottostante.

Man mano che i sistemi di IA diventano integrati nella presa di decisioni quotidiana, come dovrebbe evolversi la definizione di IA etica quando la proprietà dei dati viene trattata come un principio di progettazione fondamentale anziché come una casella di controllo delle politiche?

Una volta che la proprietà dei dati diventa un principio di progettazione, l’IA etica non è più solo questione di audit dei modelli dopo il fatto — è questione di progettazione di sistemi in cui gli utenti mantengono l’agenzia sui dati che li addestrano. L’etica diventa infrastruttura.

Grazie per la grande intervista, i lettori che desiderano saperne di più possono visitare Countly.