3. Advertising e DRM nella Net TV: cos’hanno in comune?

giovedì 21 giugno, 2007

Vediamo ora come l’advertising (d’ora in poi Adv) è coinvolto nelle nuove dinamiche introdotte con il Web2.0 (inteso come User generated) e la mobilità. Come abbiamo accennato, un primo elemento in comune che hanno l’Adv e i DRM è la necessità di essere presenti sui dispositivi Player.
L’Adv svolge un ruolo importantissimo nello scenario del mobile e della Net TV. Le nuove tecnologie hanno permesso un’evoluzione senza precedenti dell’Adv, rendendolo dinamico, interattivo e “intelligente”.
Internet, in particolare, ha permesso di sperimentare nuove tecniche d’indagine legate al marketing, ottenendo risultati di gran lunga migliori delle passate strategie, poco precise e basate sostanzialmente sul concetto di “campione”. L’Adv, tuttavia, trova difficoltà a collocarsi in modo uniforme sulle varie piattaforme e tecnologie proposte. Questo ha creato una situazione quasi paradossale che vede il manifestarsi di atteggiamenti che spaziano dall’inefficacia totale del messaggio pubblicitario ad un ottimo e inaspettato risultato con vantaggiosi ritorni.

Mobilità e Dinamicità dei contenuti

Come accade (o accadrà) con i contenuti standard, anche l’Adv deve adeguearsi a seconda del dispositivo utilizzato. La nuova era cross-devices (lo stesso contenuto può essere fruito su diversi dispositivi) indica chiaramente che lo stesso format o contenuto deve avere caratteristiche diverse a seconda del dispositivo da cui viene fruito. Un cellulare, ad esempio, permette “un’esperienza” del tutto diversa da un plasma 16:9 da 38 pollici o da uno schermo PC. I diversi dispositivi, inoltre, non sono sempre riconoscibili dal software-adv e uno standard in questo senso è il primo ostacolo da superare. Questo accade perchè oggi i dispositivi si assomigliano troppo e un software-adv potrebbe non essere in grado di riconoscerli, in modo univoco, immediatamente. Inoltre la tecnologia evolve in fretta, lasciando poco tempo agli aggiornamenti. L’introduzione dei sistemi operativi (anche se in forma ridotta o light) in alcuni dispositivi mobili produrranno a lungo termine una totale convergenza tra il PC domestico e i “PC” portatili.

Ecco, come esempio, alcune delle caratteristiche essenziali che un software-adv dovrebbe essere in grado di individuare per rendere il suo contenuto il più adatto possibile alle diverse circostanze:

  • Contenuto
    Ottenere (tramite Tag ad esempio) informazioni sul contenuto (audio o video) è un primo discriminatore, già utilizzato ad esempio nel sistema AdWords di Google, che è in grado di fornire Adv contestualizzati in base alle informazioni presenti all’interno della pagina Web ospitante
  • Data e ora
    Permette al software-adv di presentare un contenuto adeguato alla stagione e all’orario di fruizione
  • Dimensioni dello schermo
    Le dimesioni dello schermo sono essenziali per la scelta dei formati da presentare. Piccoli schermi hanno necessità di dettagli diversi e tempi di animazione diversi rispetto a schermi di maggiori dimensioni
  • Capacità audio
    Determinare la “modalità di ascolto” è anch’esso un elemento utile per determinare il tipo di sonoro da utilizzare (è inutile eseguire un digital-surround su un cellulare)
  • Dispositivi di Interfaccia
    Per i software-adv che richiedno un’interazione (vedi anche AdvGame) le diverse interfaccie oggi disponibili (mouse, tastierino telefonico, multi-touch screen, etc…) producono esperienze diverse e quindi non trascurabili ai fini di una miglior efficacia
  • Sistema operativo/Dati utente
    Una provocazione, se volete, non troppo distante dalla realtà. In alcuni dispositivi sono contenuti i nostri profili (sesso, stato, città, data di nascita, ecc…), informazioni sensibili, ma spesso accessibili dai software-adv che possono così filtrare contenuti del tutto irrilevanti per il target identificato

Questa è una delle caratteristiche più interessanti che le nuove tecnologie forniscono: rendere l’adv intelligente, in grado cioè di variare il suo contenuto in base ad una serie di parametri. Questa possibilità rende il messaggio pubblicitario estremamente più efficace, allineandosi, di fatto, alle esigenze e al contesto dell’utente finale. Il numero di informazioni ottenibile è, ovviamente, legato all’evoluzione della tecnologia. I nuovi dispositivi con GPS, ad esempio, forniranno addirittura la nostra posizione sul globo e quindi potranno rendere ulteriormente più efficaci i contenuti pubblicitari proposti: se ad esempio mi trovo al mare ad agosto fruirò piacevolmente di pubblicità sulle bevande ghiacciate o creme solari, diversamente se mi trovo in montagna sarò ben liento di “sorbirmi” uno spot sulla cioccolata calda o una coperta termina!

Insomma, per gli analisti del marketing un vero e proprio – insperato – paradiso.

Tuttavia “possibilità” non significa direttamente “fattibilità”. Gli elementi essenziali che ad oggi impediscono una diffusione di massa di questi nuovi “consigli per l’acquisti” sono:

  1. Il Player – colui che fornisce il contenuto e l’adv
  2. La gestione di tutte le varianti dell’adv

Il Player

Il software-adv sopra “immaginato” ha necessità di essere integrato nel sistema di fruizione, sia esso audio o video. Pensarlo come elemento separato lo rende inefficace e più facile di essere bypassato da chiunque. Dovranno essere quindi i Player e gli aggregatori ad incorporare l’intelligenza software-adv, così da fornire un’unico sistema di fruizione che permetterà al software-adv di sincronizzarzi anche con il contenuto fruito, anch’esso fonte di informazione per adeguare il messaggio pubblicitario: se guardo un puntata di CSI invece che di Ballarò fornisco informazioni sui miei interessi.
Il Player, in questa visione, è paragonabile al browser Internet che all’interno della stessa pagina Web mostra sia i contenti dell’autore che eventuali messaggi di Adv.

Distribuzione dell’Adv: online vs offline

Se pensiamo poi di essere entrati nell’era dell’online continuo potremmo rimanere davvero delusi. Nonstante la connessione alla rete sia oggi estremamente diffusa e veloce rispetto a qualche anno fa, molti software non danno affatto per scontato di “trovarsi in rete”. Può sempre capitare, infatti, che per un motivo e per l’altro, si rimanga fuori rete… soprattutto in Italia!
Tutto ciò è dimostrato dallo sforzo che ultimamente si sta facendo nella stesura di applicazioni in grado di funzionare sia in modalità online che offline. Le tecnologie come Adobe AIR e le nuove caratteristiche di FireFox 3, indicano la necessità di poter lavorare scollegati ed aggiornare tutti i nostri dati a tempo debito. Strumenti come Windows Live Writer puntano sulla capacità dipoter scrivere Post offline ed aggiornarli a tempo debito in rete!
Questo sicuramente indica che l’Adv non potrà essere totalemtente online, altrimenti non funzionerebbe in tutti i casi (e sono molti) di uso offline. La prima difficoltà, quindi, è immagazzinare i contenuti in una memoria statica, contenuta nel nostro dispositivo e accessibile a prescindere dallo stato di connessione.
Una possibile soluzione potrebbe risiedere in un sistema ibrido, in grado cioè di recuperare dalla rete i nuovi contenuti adv e posizionarli in una cache sul Player così, in caso di assenza di rete (offline) potranno essere visualizzati comunque gli ultimi adv, anche se non “aggiornatissimi” (tuttavia coerenti). Nonostante queste difficoltà la separazione dell’adv dal contenuto è un passo avanti, sia per l’utente finale che per gli sponsor.

Hackering

Proprio per queste sue nuove caratteristiche l’adv asincrono potrebbe rilevarsi un’arma a doppio taglio. La sua invasività potrebbe essere presa di mira da qualche Hacker. Inoltre essendo una tecnologia presente nel Player anche quest’ultimo potrebbe essere sostituito da un Player-personalizzato (o “hackerato”) in grado di eludere l’adv!

Questo punto, probabilmente, è quello che lega meglio Adv e DRM. Nell’informatica le “protezioni-software” (anche quelle hardware che hanno avuto scarso successo) posso essere potentissime o totalmente inutili, soprattutto quando si parla di sistemi aperti, semplici da utilizzare, e che coinvolgono – poi – lo User-Generated.

Esistono, ad esempio, estensioni e Plugin per gli odierni browser in grado di filtrare le pubblicità, banner e i “famosi” popup, in modo abbastanza efficiente e semplice! Eliminadoli completamente dalla pagina visualizzata.

Come esposto per i DRM, anche per l’adv la soluzione potrebbe risiedere in un nuovo approccio, un modo diverso di presentare il messaggio pubblicitario rendendo minima l’invasività e il fastidio. Bisogna far si che sia l’utente, in qualche modo, a fruire del messaggio pubblicitario, vestendo quest’ultimo con le nuove dinamiche permesse dalle tecnologie odierne.

Ma il vero nodo, forse, non risiede proprio negli stessi file audio, video e via discorrendo?

Dal file all’iFile

La portabilità di un file immagine (JPG, GIF, TIFF, etc…), audio (MP3, AIFF, WAV, etc…), di un documento PDF o di un filmato MPEG (FLV, AVI, MPG4, etc…) è strettamente legata al fatto che un file di questo tipo contiene solo ed esclusivamente le informazioni inerenti all’oggetto in questione: un file immagine, ad esempio, contiene le informazioni sull’immmagine bitmap e la sua struttura interna non tiene in considerazione il sistema operativo o il tipo di dispositivo su cui verrà poi visualizzata l’immagine. Oggi, infatti, è possibile leggere (e scrivere) un file immagine in formato JPG (uno dei più diffusi) con moltissimi dispositivi: cellulari, lettori DVD, Personal Computer, Notebook, PSP, etc…
La stessa cosa vale anche per gli altri media: audio e video soprattutto!
Quello che è accaduto, in definitiva, è che nel tempo sono stati i dispositivi ad adeguarsi ai formati (immagine, audio, video, etc…) più diffusi, e non il contrario.
Con i file – cosiddetti – eseguibili, un “programma” per intenderci, cioè file che contengono codice macchina e quindi intelligenza, la questione è assai più complessa. Un’applicazione per Microsoft Windows, ad esempio, può essere eseguita solo su un ben determinato tipo di sistema operativo. Questo comportamento è valido per tutte le piattaforme oggi in commercio: un gioco per Playstation non è utilizzabile su Mac e un’applicazione per Unix non è utilizzabile per il Nokia N70!
Nonostante esistano ambienti Virtual Machine ed emulatori, un’applicazione nel 98% dei casi funziona solo sul dispositivo/sistema operativo per cui è stata scritta. Proprio per questo, infatti, esistono versioni differenti dello stesso prodotto: Microsoft Word per Mac e Windows, il gioco Spiderman 3 per Playstation 3 e XBOX 360, il browser Opera per il Nokia con sistema operativo Symbian, ecc… Un vero e proprio universo! In definitiva se si possiedono più dispositivi bisogna acquistare la “copia” del gioco o dell’applicazione scritta (o compilata) appositamente per il nostro dispositivo.
Tali differenze ci sono sempre state ovviamente, dai tempi del Commodore 64 e dello ZX Spectrum, anch’essi incompatibili. Tuttavia ultimamente è stato possibile intravedere una possibile soluzione o, quantomeno, una “speranza” di soluzione! Con Java, tanto per citarne uno, si è creato un “terzo” mondo virtuale dove la stessa applicazione (per stessa intendo lo stesso file) è in grado di funzione su diversi dispositivi e sistemi operativi. Il trucco risiede nello sviluppare una “terza” entità (una virtual machine), renderla disponibile per tutti i diversi dispositivi e sistemi operativi, cosìcchè, da quel momento in poi, si potrà sviluppare un’unica versione di un’applicazione che vive in quest’ambiente virtuale, disinteressandosi del resto.
In quest’ottica, ad esempio, un browser funge proprio da virtual machine nei confronti del “codice” HTML. Internet è stata pensata ed ha avuto il suo “successo” grazie proprio a questo comportamento peculiare rispetto alle applicazioni tradizionali. Un sito Web, infatti, propone il medesimo codice HTML senza preoccuparsi del tipo di dispositivo o sistema operativo che ne fruirà (anche se oggi, in verità, questo non è del tutto vero al 100%, ma la sostanza rimane). Le cosiddette Web Application, che hanno aperto l’era del Web2.0, permettono a chiunque di essere utilizzate semplicemente dispondendo di un browser, non richiedono installazione e, in via teorica, funzionano dapperttutto!

Soluzioni come Adobe AIR, in effetti, pongono l’accento proprio su questo fondamentale concetto: distribuire un run-time (una virtual machine) per le diverse piattaforme e dispositivi così da permettere un unico sviluppo del codice, rendendo un’applicazione facilmente portabile da un sistema ad un altro, al pari di un’immagine JPG! Questo approccio potrebbe avere delle ripercussioni anche sui file dati tradizionali che diventerebbero, concedetemi il neologismo, degli iFile (o se preferite Media Application File – MAF), ovvero “file-intelligenti”, ibridi tra file dati tradizionali e applicazioni portabili.
Quali sarebbero i vantaggi? Ad esempio si potrebbe pensare di fornire un video o un brano musicale non come file dati, come accade oggi, ma come applicazione (o iFile). Un’applicazione, ovviamente, portabile, cioè funzionante su diversi dispositivi grazie all’adozione di uno standard (runtime/virtual machine) distribuito su DVD Player, Televisori, iPod, Playstation, PC, Notebook, cellulari, ecc…
Avendo quindi a disposizione il nostro video o audio come applicazione, questa potrà gestire sia i DRM che l’Adv, avendo fuso in un unico “elemento” sia il Player che e dati.

Si perderebbe così la centralità del dato grezzo! Un’immagine non sarebbe più solo “immagine” ma incorporerebbe anche il visualizzatore: diventerebbe quasi “autocosciente”. Un’involucro, quindi, che può contenere qualsiasi tipo di informazione: audio, video, testo, ecc…

Facendo un paragone con la programmazione informatica, per i soli tecnici, è come passare dal C al C++, dove le strutture (struct) dei dati grezzi diventano oggetti! O il salto evolutivo portato da Flash nelle “statiche” pagine Web!

Un video non rappresenterebbe più solo un flusso di dati. Incorporando il suo Player il formato di compressione usato potrebbe essere qualsiasi. Questo iFile sarebbe in grado di fare tante cose, proprio perchè “applicazione”. Oltre a manipolare Adv e DRM in modo embed potrebbe fornire tutta una serie di servizi, proprietà ed eventi oggi demandati ai vari tipi Player (e sono tanti) sparzi nei diversi dispositivi e sistemi operativi esistenti.

Conslusioni

Questo scenario, tuttavia, è lungi dall’essere realizzato in tempo breve, salvo sorprese! Prima di tutto lo standard, discusso nella prima parte di questa serie di Post, riveste un ruolo fondamentale. Per rendere reali e realistici gli iFile serve prima di tutto una virtual machine unica per tutti i sistemi e per tutti i dispositivi: Java? Adobe AIR? Sono alcuni dei condidati oggi presenti.
Un file audio o video diventerebbe più pesante, proprio perchè incorpora una serie di dinamiche aggiuntive al suo interno. Qualcuno potrebbe giustamente rivelare una certa ridondanza nell’avere 100 brani musicali con lo stesso codice Player “a bordo”! Tuttavia potrebbe essere un “prezzo” accettabile per risolvere DRM e Adv in un colpo solo; anche se la domanda è: verrebbero davvero risolti senza agire anche sulle modalità con cui si fa “politica” DRM e Adv?

Possiamo riassumere parzialmente i Pro e i Contro degli ipotetici iFile qui di seguito:

  • Pro
    • Gestione embed e personalizzata dei DRM
    • Gestione embed e personalizzata dell’Adv
    • Possibilità di rendere dinamico, interattivo ed inteligente un elemento tradizionalmente “inerte”
    • Forniitura di servizi sotto forma di metodi, proprietà ed eventi: qui si apre un’universo, a mio avviso, a seconda del tipo di dato trattato. Per un brano musicale, ad esempio, possibilità di accedere all’immagine della copertina, al testo del brano (in lingue diverse). Per un video interazione, Adv contestualizzato a livello di frame, multiple inquadrature, sottotitoli, ecc…
  • Contro
    • Parziale scomparsa dei “file dati” tradizionali: questi rimarrebbero dove non sono richieste le caratteristiche aggiuntive degli iFile
    • Aumento dello spazio occupato: in termini bytes
    • Evidenti ripercussioni sulla libera distribuzione e sulla banda di trasmissione
    • Formati proprietari per la protezione dei DRM e dell’Adv skipping

La parte più controversa, tuttavia, rimane la difficoltà di determinare quanto “aperto” dev’essere una file di questo tipo. Per tutelare DRM e Adv, un iFile immagine, ad esempio, non potrebbe essere aperto con Adobe Photoshop con la semplicità con cui si fa oggi. Inoltre la chiusura dei formati di questi file limiterebbe – per non dire annullerebbe – produzioni software open source, freeware o shareware, rendendo quest’ultime “illegali”. Insomma, la protezione migliore rischia quasi sempre di uccidere proprio quello che si vuole proteggere! Il classico cane che si morde la coda.
Da sviluppattore, poi, so benissimo che tutto può essere “hackerato” (viva il debug), è sempre e solo una questione di tempo!

Post correlati

Questo articolo ti è stato utile?: Per nientePocoAbbastanzaMoltoMoltissimo
Loading ... Loading ...

Un commento a: “3. Advertising e DRM nella Net TV: cos’hanno in comune?”

  1. 21 giu, 2007 University Update - Microsoft Windows - 3. Advertising e DRM nella Net TV: cos’hanno in comune?:

    [...] YouTube Link to Article microsoft windows 3. Advertising e DRM nella Net TV: cos’hanno in comune? » Posted at undolog on Wednesday, June 20, 2007 Tags: advertising, DRM, DTT, Internet, Mobile, Net TV, Software, Sviluppo, Tecnologia Vediamo ora come l’advertising (d’ora in poi Adv) è coinvolto nelle nuove dinamiche introdotte con il Web2.0 (inteso come User generated) e la mobilità. Come abbiamo accennato, View Entire Article » [...]

Lascia un commento

TAG XHTML PERMESSI: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> INSERIMENTO CODICE:
<pre></pre>         // blocco generico
[code][/code]       // blocco generico
[as][/as]           // Actionscript
[css][/css]         // CSS Style Sheet
[html][/html]       // HTML
[js][/js]           // Javascript
[objc][/objc]       // Objective-C
[php][/php]         // PHP
[sql][/sql]         // SQL