strumenti di marketing

Tecnologia e strategia

Costruire un portale E-Commerce funzionale, in grado di gestire migliaia di prodotti e presentarli con una grafica accattivante, in ottica mobile first…può non bastare!

Se infatti mancheranno le visite al nostro sito, ovviamente non avremo conversioni e nonostante i nostri prodotti possano essere migliori della concorrenza, il nostro business non potrà decollare.

Spesso, quindi, adottare soluzioni di advertising può essere la scelta migliore, soprattutto se si vogliono ottenere risultati a medio-breve termine. Nell’ambito online, il più grande network pubblicitario verso cui potremmo indirizzare le nostre risorse è ovviamente Google.

Scegliere Google e Magento

Il ruolo di Google nell’advertising online

8 domini Google, come ad esempio il motore di ricerca Google.com, YouTube o Google Maps, sono capaci di portare, ognuno, oltre 1 miliardo di utenti verso i vari siti internet mondiali.

Questo ruolo primario di Google è evidente a tutti e le aziende possono trarre beneficio da questi numeri impiegando le sue soluzioni pubblicitarie, così da intercettare un’utenza interessata per aumentare awareness, visite e ovviamente conversioni sul proprio sito.

Sono moltissime le aziende che decidono di investire una parte del proprio budget nel network pubblicitario di Google, scegliendo le campagne più opportune. Ad esempio, quelle di Google Shopping sono un’ottima soluzione per pubblicizzare i propri prodotti E-Commerce, comprendendo immagini, testi e caratteristiche.

Tuttavia molte aziende, soprattutto quelle con grandi cataloghi di prodotti (che magari utilizzano l’interessante soluzione di Product Information Management), fanno fatica a gestire e ottimizzare queste campagne su Google, ottenendo scarsi risultati e quindi, alla fine, abbandonando questa interessante strategia di marketing.

Perché fare advertising con Magento

Quali problemi nella gestione di campagne di marketing online

Il problema della gestione delle campagne Google accomuna aziende grandi e piccole. Se l’advertising online consente grande flessibilità e immediatezza, è altrettanto certo che solamente attraverso un’attenta ottimizzazione si potranno ottenere dei risultati significativi.

Le aziende purtroppo riscontrano diversi problemi legati ad una mancanza di integrazione tra i propri sistemi e quelli di Google, scarsa esperienza del proprio personale oppure soluzioni di terze parti che non offrono realmente ciò che l’azienda avrebbe bisogno.

Fortunatamente, Magento permette di superare numerose lacune offrendo la possibilità di creare, gestire e ottimizzare le campagne Google in modo integrato, semplice e funzionale, grazie all’integrazione Google Shopping Ads.

La tua soluzione per l’advertising online

Magento e l’integrazione Google Shopping Ads

Google Shopping Ads Channel è la soluzione di Magento perfetta per aiutarti a coinvolgere i tuoi utenti tramite campagne di Google ottimizzate ed integrate.

Grazie a questa estensione, non ci saranno più problemi né limiti nella gestione delle tue attività di advertising su Google, aiutandoti ad ottimizzare i tuoi sforzi direttamente dall’interfaccia di Magento.

Sarà infatti davvero semplice creare l’account di Google Merchant Center e verificare il tuo sito internet collegato, senza abbandonare Magento. Questo renderà anche più veloce il tuo flusso di gestione aziendale, permettendoti di risparmiare tempo e risorse per focalizzarsi sugli aspetti davvero rilevanti delle tue campagne di marketing.

Principali vantaggi di Google Shopping Ads Channel con Magento

Unica soluzione

Dall’interfaccia di Magento sarà possibile creare, gestire ed ottimizzare le campagne in tutte le fasi.

Integrazione nativa

Gestisci tutte le soluzioni di Adversiting di Google tramite l’interfaccia familiare di Magento e focalizzati sui dati più importanti per ottenere il miglior ROI, grazie a report dettagliati e completi.

Semplicità e rapidità

Integrazione campagne con pochi click. Con semplicità e velocità potrai creare le campagne che desideri, liberandoti da inutili problemi di gestione.

Funzionalità avanzate

Attraverso Google Shopping Ads Channel integrato in Magento potrai fare davvero tutte quello che vorrai. Sarà infatti, ad esempio, attiva anche la possibilità di creazione di Smart Campaigns, che sfruttano l’enorme potenziale del Machine Learning.

Sincronizzazione con il catalogo

Avere un’unica interfaccia di gestione rende molto semplice anche aggiungere o cambiare i dettagli dei prodotti, anche con l’integrazione del PIM. Non dovrai più preoccuparti dei prodotti non disponibili in magazzino o di variazioni di prezzo.

Aumenta il tuo traffico

La soluzione di advertising di Google ti consentirà di aumentare il traffico di utenza interessati verso il tuo E-Commerce. Non c’è investimento minimo e paghi solo quando ottieni i risultati.

Noi di Dotcom possiamo aiutarti nella creazione di portali E-Commerce con Magento che sfruttino anche gli strumenti di marketing di Google. Contattaci per scoprire di più.

ARCHITETTURA E SVILUPPO AGILE

Definizioni di Architettura

Gli sviluppatori che adottano metodologie “Agili” hanno spesso opinioni contrastanti riguardo all’architettura di un software, a volte addirittura arrivando a dire che l’architettura non esiste.

Proviamo a ragionarci e cerchiamo prima di tutto di dare delle definizioni di architettura:

  • Architettura: decisioni difficili da riconsiderare in quanto il rivederle avrebbe un costo eccessivo
  • Architettura software: la “forma” e il “flusso” di un software indipendentemente dal dominio del problema ma dipendente dalla user-experience

Vediamo le definizioni singolarmente.

Architettura in termini generali

Molti dei “guru” in campo informatico hanno dato la loro definizione di architettura. Prendiamo ad esempio Simon Brown che nel suo doppio volume Software Architecture for Developers dice:

“Architetcture represents the significant decisions that shape a system, where significance is measured by cost of change”

ossia “L’archiettura è rappresentata dalle decisioni significative che danno forma al sistema, dove la “significatività” è misurata in termini di costi necessari per cambiarle” e prosegue con “The architectural decisions are those that you can’t reverse without some degree of effort” ossia “Le decisioni architetturali sono quelle che non si possono rivedere senza l’impiego di una certa dose di effort”.

Le tre macro-architetture software più largamente e comunemente utilizzate sono:

  • Request/response. Viene fatta una richiesta al sistema e si attende la risposta
  • Event driven. Gli Eventi di business avvengono e gli Attori del sistema devono reagire ad essi. Lo stato del sistema può essere interrogato
  • Batch. Il Sistema processa i dati senza l’intervento dell’utente a intervalli più o meno stabiliti.
Macro-Architetture 1

Dettagli architettura request/response

È molto comune per le web-application avere una architettura request/response, per quanto diversi possano essere i domini applicativi quasi tutte ricadono nello stesso schema di domanda e risposta (request/response appunto).
Non solo! Se consideriamo gli applicativi a linea di comando si può vedere che anch’essi seguono una architettura di tipo request/response e se andiamo ad esaminare il loro codice si potrà verificare che sono strutturati in maniera simile alle web-application.
Indice quindi che, come detto, l’architettura software è indipendente dal dominio applicativo ma dipende dalla user-experience prevista.

Macro-Architetture 2

Dettagli architettura event-driven

Un videogame, invece, è il tipico esempio di una architettura di tipo event-driven in cui gli attori e gli eventi avvengono, anche, indipendentemente da quanto stia facendo l’utente.
Allo stesso modo molti sistemi distribuiti seguono una architettura di tipo event-driven in cui i vari nodi reagiscono e generano eventi che vanno a cambiare lo stato complessivo del sistema.
Un’altra volta vediamo come l’architettura non è definita dal dominio, e quindi dai requisiti funzionali, bensì dalla user-experience e dai requisiti non funzionali.

Macro-Architetture 3

Dettagli architettura batch

Un ragionamento analogo può essere fatto per i sistemi basati su architetture di tipo batch in cui il sistema processa i dati senza la necessità di intervento di un utente. Sono tutti strutturati in maniera simile indipendentemente dal dominio applicativo.

Risulta chiaro che il dover cambiare tipo di architettura (ad esempio da request/response a event-driven) è un’operazione molto onerosa e rischiosa.

Quando gli sviluppatori Agile determinano l’architettura?

Lo sbaglio che molti sviluppatori agili fanno è pensare che l’architettura di un sistema emerga spontaneamente semplicemente applicando le tecniche di TDD (Test Driven Development) e Refactoring, cosa che invece non succederà.
L’architettura è una decisione critica, di fatto non sarebbe nemmeno possibile iniziare a fare del TDD prima di aver definito l’architettura in quanto i test sono necessariamente vincolati a come il software sarà strutturato e a come il “flusso” sarà definito.

Questo implica che l’architettura deve essere definita prima di iniziare lo sviluppo.

Ma, allo stesso tempo, un bravo sviluppatore agile sa bene che non è possibile, e non ha nemmeno senso provarci, cercare di capire e carpire tutti i dettagli di un nuovo sistema preventivamente e tardare gli sviluppi fino a quel termine. Sa invece che prima riuscirà a dare al cliente un sistema funzionante prima riuscirà ad avere dei feedback e capire quali assunzioni fatte erano giuste e quali sono sbagliate andando di conseguenza ad aumentare la propria conoscenza sul dominio e su che tipo di user-experience il cliente si aspetta.

Questo implica che l’architettura verrà definita anche durante lo sviluppo del software.

Sebbene le due asserzioni siano contrastanti questa è la realtà dei fatti che non può essere ignorata e significa che nuove user-stories (requisiti funzionali) potranno indicare delle user-experience o dei vincoli (requisiti non funzionali quali performance aspettate, high availability, sicurezza) che non si sposeranno bene con l’architettura precedentemente impostata.
Quello che un bravo sviluppatore agile dovrà fare non sarà tanto snaturare quanto richiesto dal cliente per includerlo in un’architettura non adatta bensì dovrà o rivedere l’architettura in toto o far accomodare nel proprio sistema diverse architetture. Ovviamente la cosa non è semplice e richiederà abilità e tempo, condizioni che dovranno essere illustrate, discusse e spiegate al cliente.

Architettura e metodologia Agile

Conclusioni

Dato che l’architettura è la parte più costosa da rivedere in un sistema allora è bene porre particolare attenzione alla sua prima definizione.

Essendo l’architettura definita dalla user-experience aspettata (in primis se request/response o event-driven) e dai requisiti non funzionali, anche detti di qualità, come le performance, la SLA richiesta, il numero di utenze previste e il livello di sicurezza allora è necessario chiarire innanzitutto tali aspetti con il cliente, ancora prima di avere chiaro il dominio applicativo.

Come tutto durante lo sviluppo di un software anche tali aspetti possono cambiare e bisogna reagire di conseguenza o cambiando architettura o incorporando più architetture nel sistema. In tali casi va fatta capire al cliente la necessità e la complessità dell’operazione che risulta però necessaria per raggiungere gli obiettivi richiesti.

Piano straordinario di SmartWorking

Si è beneficiato del sostegno finanziario del Programma Operativo del Fondo Sociale Europeo della Regione Autonoma Friuli Venezia Giulia in relazione al programma PS 101/2020 – “Sostenere l'adozione di modelli innovativi di organizzazione del lavoro attraverso lo sviluppo di piani aziendali e l'adozione di adeguata strumentazione informatica per adottare strumenti di lavoro agile ovvero di smart working. Emergenza da COVID- 19”

Dotcom Fondo Sociale Europeo Loghi