Local blog for Italian speaking developers
Miglior targeting di utenti con Firebase Remote Config
7 novembre 2016
Una delle mie funzioni preferite di Firebase Remote Config è la capacità di fornire contenuti diversi a gruppi di utenti diversi. Ad esempio, è possibile modificare l’aspetto della vetrina per le persone che hanno speso parecchi soldi nella tua app oppure evidenziare una parte della tua app di fitness per i corridori e un’altra per i pesisti.
Sin dal primo lancio di Remote Config, è stato possibile realizzare un targeting di utenti piuttosto complesso per la distribuzione di contenuti diversi a persone in
segmenti di pubblico
di Firebase Analytics differenti.
Ma più recentemente, Remote Config ha aggiunto la funzionalità di invio di set di dati diversi a persone con proprietà utente diverse, rendendo questa caratteristica ancora più utile.
Potresti pensare: "Aspetta un attimo, però". "Posso già rivolgermi all’utente di destinazione grazie ai segmenti di pubblico, che mi consentono di utilizzare un targeting più focalizzato rispetto alle semplici proprietà utente. Quindi perché sarebbe migliore questo metodo?".
Infatti hai ragione. I segmenti di pubblico ti offrono tipi di targeting molto potenti e specifici consentendoti di creare gruppi di utenti che possono essere definiti da una serie di proprietà utente e da eventi diversi. Ad esempio, puoi creare un segmento di pubblico di "Canadesi mancini che hanno completato il livello 5 del mio gioco".
1
Purtroppo i segmenti di pubblico presentano due limitazioni che possono rendere più complicato l’utilizzo nell’ambito di Remote Config.
La prima è che hai un limite di 50 segmenti di pubblico, condivisi da molte persone che potrebbero utilizzarli per altre funzioni di targeting all'interno di Firebase, come l’esecuzione di report Analytics o la creazione di campagne di remarketing con Google AdWords. Ciò rende più difficile la creazione di diversi piccoli gruppi di utenti ad hoc o la modifica di segmenti di pubblico esistenti che altre persone all'interno dell'organizzazione potrebbero utilizzare.
La seconda è che, in base al modo in cui funzionano attualmente i segmenti di pubblico, una volta che un utente fa parte di uno di questi segmenti, non potrà più lasciarlo. Per il classico marketer che sfrutta i segmenti di pubblico per le campagne di remarketing, potrebbe essere esattamente ciò che si aspetta, ma ai fini di Remote Config, potrebbe dare dei problemi.
Immagina di voler creare un segmento di pubblico "Principianti", ossia composto da persone che hanno iniziato il tuo gioco ma non hanno ancora completato il livello 10. Se hai provato a creare un segmento di pubblico da questo gruppo, chiunque abbia iniziato a giocare, ne farà parte. Purtroppo però, anche se raggiunge il livello 15 o 20, l’utente rimarrà in questo segmento di pubblico, che in sostanza, si trasforma nel segmento "Tutti i giocatori".
Per questo motivo, quando eseguo il targeting degli utenti in Remote Config, preferisco usare le Proprietà utente per personalizzare i miei contenuti. Mi consentono di creare tanti piccoli gruppi di targeting occasionali con un comportamento un po’ più dinamico rispetto ai segmenti di pubblico tradizionali.
Ad esempio, supponiamo che tu abbia un'app di fitness e voglia offrire un'immagine in prima pagina diversa in base all'attività fisica preferita dell'utente. Se stabilisci che l'esercizio fisico preferito sia archiviato come una proprietà utente, puoi impostarlo facilmente creando una nuova condizione basata su quella proprietà.
Quindi è possibile mostrare un’immagine diversa in prima pagina in base a ciascuna di queste condizioni.
In tal modo, puoi facilmente creare una mezza dozzina di condizioni diverse e non preoccuparti di "aver finito" tutti i segmenti di pubblico disponibili in Firebase Analytics.
2
Oppure, se hai un’app di gioco, immagina di voler cambiare alcuni elementi del gioco in base al livello dell'utente. Puoi farlo archiviando quel livello come una proprietà utente e creando quindi una serie di condizioni diverse basate su questi tier. Ad esempio, possiamo creare un gruppo "intermedio" di giocatori ai livelli 4-10...
E dare un bonus giornaliero diverso a questi giocatori.
Se gli utenti avanzano di livello, Remote Config comincerà automaticamente ad attribuire valori diversi in base al loro livello quando la proprietà utente li assegna a tier differenti. Quindi non c'è bisogno di creare un nuovo segmento di pubblico per ciascuno di essi.
E sarà anche semplice cambiare questi raggruppamenti in seguito. Se in futuro decidiamo che il livello intermedio debba iniziare dal livello 6, possiamo apportare questo cambiamento all'interno del pannello di controllo Firebase, e qualsiasi modifica verrà immediatamente comunicata a Remote Config.
Addirittura un quarto tier può anche essere aggiunto se decidiamo di voler cambiare il comportamento del gioco solo per alcuni giocatori speciali.
Per impostazione predefinita, le proprietà utente sono archiviate come stringhe, ciò significa che con loro è possibile eseguire confronti di stringhe come "corrisponde esattamente" o "contiene". Se hai archiviato le 3 attività top di fitness del tuo utente come una stringa separata da pipe (ad esempio
yoga|interval_training|running
), puoi creare una condizione “Tutti i corridori" avendo come obiettivo tutti coloro la cui attività di fitness contiene la stringa "corsa".
Puoi anche eseguire confronti numerici con loro, come abbiamo indicato nell'esempio playerLevel precedente. Remote Config tradurrà le stringhe in numeri, come previsto:
"42"
diventerà 42,
"3.14159"
diventerà 3.14159 e così via. Tuttavia i confronti numerici con le stringhe di proprietà utente che non si convertono in numeri interi o valori a virgola mobile (ad esempio
"Level_42"
) non avranno mai un esito positivo.
Poter eseguire il targeting con le proprietà utente è una funzione relativamente nuova, quindi se non l’hai mai provata, ti incoraggiamo a farlo. Visita il
pannello di Remote Config
e prova a effettuare una piccola modifica basata su una proprietà utente che hai già archiviato. Una volta sistemato questo aspetto, prova a pensare a quali parti della tua app potrebbero davvero trarre vantaggio da un po’ di personalizzazione e considera l'aggiunta di una o di un paio di altre proprietà utente per supportarla.
E se alla fine crei qualcosa di interessante,
faccelo sapere
! Ci farebbe molto piacere vederlo.
Pubblicato da
Todd Kerpelman
, Developer Advocate
1
In questo caso si presume che abbia eseguito il targeting dell’"impostazione della mano usata" come una delle proprietà utente.
2
A dire il vero, esiste anche un limite per il numero di condizioni che è possibile creare in Remote Config, ossia 100, quindi in ogni caso un numero decisamente maggiore.
Pubblicato da Todd Kerpelman Developer Advocate
Etichette
Android
Firebase
machine learning
Google Cloud Platform
GDL
Eventi
Google Developers Live
Google Play
TensorFlow
App
Chrome
Cloud
api
GDLItalia
GDE
GDG
Google Assistant
iOS
Kotlin
Actions on Google
Deep Learning
AppEngine
AMP
BigQuery
Cloud Functions
Flutter
Android Studio
Google Developers Expert
Università
Google AppEngine
JavaScript
AI
Android Wear
GAE
Google Play Store
HTML5
Maps
security
Android App Development
AngularJS
IoT
Kubernetes
Annunci
Cloud Firestore
Cloud Machine Learning
Google I/O
Polymer
Android Things
Community
DevTools
Google App Engine
intelligenza artificiale
Entrepreneurship
Firebase Analytics
GSoC
Games
Google Cast
ML
open source
Crashlytics
Dart
Diversity
Drive
Google Data Studio
Google Play Games
TensorFlow Lite
Android Developers
Android O
Cloud Spanner
Cloud TPU
Compute Engine
DevFest
Google Compute Engine
Google Developers
Material Design
Mobile
PWA
Python
Startup
AIY Project
ARCore
Android Jetpack
AndroidDev
Androidq
Apps Script
Artificial Intelligence
Augmented Reality
Firebase Cloud Messaging
Google Cloud
Google Maps
Gsuite
IO19
ML kit
Research
VR
coding
unity
#io19
AR
Android Dev Summit
Android Developer
Android Q
Cardboard
Cloud AI
Coral
Developers
Dialogflow
Firebase Realtime Database
Gmail
Google AI
Google Cloud Messaging
Google ContainerEngine
Google Play Console
Kotlin Coroutines
NLP
Programming
Responsive Design
TensorFlowjs
Testing
WTM
Women
beacons
cloud storage
developer
node JS
student programs
women techmakers
API Cloud Vision
Add-ons
Android P
AndroidDevStory
Animation
AutoML
Brillo
Classroom
DSC
Database
Developer Student Clubs
Edge TPU
Fabric
Featured
Flutter Web
G Suite
GWT
GoLang
Google
Google Brain
Google Cloud Next
Google Container Engine
Google Developer Groups
Google I/O Extended
Graph
Hosting
Instant Apps
Keras
Livedata
Mobile Sites
Prediction
Privacy
Project Tango
SDK
Stackdriver
Tales
UI
Udacity
Virtual Reality
Web
Web Development
YouTube
analytics
android security
api.ai
courses
google io
indies
natural language processing
reti neurali
sign-in
young developers
2d Animation
3d
AIY
ARkit
Adversarial Learning
Alpha
Android App
Android App Developmen
Android App bundle
Android Architecture
Android Architecture Components
Android Auto
Android Automotive OS
Android Dev Summit Android Developer
Android Developer Challenge
Android Developers GooglePlayAwards
Android Development
Android Go
Android Instant App
Android Pie
Android Q Scoped Storage
Android Q audio
Android Styles
Android audio playback capture
Android codelabs
AndroidTV
AndroidX
Angular
Aogdevs
Api Design
App Development
App Distribution
Apps
Architecture
Architecture Components
Arduino
Best Practices
Betatesting
Bugs
C++
Certification
Cloud Anchors
Cloud Next
Cloud Run
Cloud Service Platform
Cloud Shell
Cloud Study Jam
Coached Conversational Preference Elicitation
Commerce
Community Connector
Computer Science
Consistency
Containers
Converge
Conversation Design
Crash Reporting
DLS Design
Dagger
Data Science
Databases
Dependency Injection
Design
Developer Communities
Developer Community
Developer Culture
Developer Story
Developing Media Apps
Development
Eager
Edge TPU Dev Board
Education
Emulatore Android
Error Message
Eslint
Europe
Firebase Extensions
Firebase Summit 2019
Firebasehosting
Flutter 1.5
Flutter at IO
FlutterDark
GCE
GDD
Game Development
Gboard
Gesture Navigation
Glass
Go
Google AI Quantum
Google App Script
Google Cloud Functions
Google Cloud billing
Google Coral
Google Developer Days
Google Home Hub
Google IOS Android
Google Identity Platform
Google Launchpad
Google Lens
Google Now
Google Photos
Google Play Devs
Google Play Indie Games Festival
Google Play Instant
Google Plus
Google codelabs
Google+
GoogleDevWeekly
GoogleLaunchpad
GooglePlay
Graphics
Healthcare
I/O
IO
IO19 Flutter
In-app Billing
Indie Games
Indie Games Festival
Indie games showcase
Indie showcase
Ingress
Instant Games
Issues
Java
Jetpack
Knative
Kotlin Beginners
Kotlin Everywhere
Kotlin codelabs
Lighthouse
Live Caption
Live Streaming
Localization
Location
M-Theory
Mondaygram
Monetization
NYT
NativeScript
Navigation
Neural Graph Learning
Neural Structured
Nodejs
OS
OS Updates
Olivex
One Time Codes
Online Education
PHA
Performance Monitoring
Policy
Posenet
Project Mainline
Project Treble
Quantum Computing Theory
Reactive Programming
Regression
Remote Config
Resonance Audio
Room
Scoped Storage
Semantics
Semi Supervised Learning
Serverless
Sms Retriever Api
Sms Verification
Speech Recognition
Swift
Tensorflow Core
Tensorflow Hub
Test Lab
Text
Tokenizer
Tpu
Transformers
UX
UX Design
UX Research
Universal Sentence Encoder
Unsupervised Data Augmentation
Unsupervised Learning
User Experience
Viewmodel
Voice
WWW
Wear OS
WebAssembly
Widget
Women in Tech
WomenTechmakers
android kotlin
app stability
assistant
audio recording
augmented faces
authsub
best practices and updates
billing
botnet
business
c++ games
cancer
chatbot
chrome privacy
codelab
codelabs
competition
daydream
designer
dominio .dev
error handling
event
firebase games
firebase gdc
firebase hosting
firebase unity
game center authentication
game testing
games authentication
gdc
google summer of code
googledevelopers
grow
hashcode
indie
indie developers
internship
kids
machine intelligence
machine learning accelerator
maker
multi-platform
nearby
oauth
openid
performance
persistent AR
privacy sandbox
prizes
prototype
purchase flows
queries
realtime
responsible AI
security rules
showcase
solutions challenge
startup africa roadtrip
startup times
students
summer of code
unity crashlytics
verify apps
win
Archivio Blog
2020
feb
gen
2019
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2018
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2017
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2016
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2015
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2014
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
2013
dic
nov
ott
set
ago
lug
giu
mag
apr
mar
feb
gen
Feed
Follow @GoogleDevsItaly
