As APIs do Experience permitem que você veicule conteúdo do mesmo website tanto na web quanto em apps móveis, além de criar um perfil de cliente unificado em ambos os dispositivos ao implementar eventos de identificação com valores correspondentes.
Todos os seus dados e recursos, como suas estratégias de recomendações, são armazenados de forma centralizada em uma única seção na Dynamic Yield. Seus usuários podem ser referenciados por um único ID de usuário em todas as suas plataformas, em vez de gerenciar diferentes IDs de usuário em cada plataforma. Isso possibilita que você construa um perfil de usuário mais abrangente, que por sua vez melhora nossas estratégias de recomendações e oferece aos usuários uma experiência de navegação coesa em todas as suas plataformas.
Por exemplo, o usuário navega em uma categoria de produtos (digamos, calçados) pela primeira vez em seu app móvel. Em sua próxima visita ao seu website, o usuário vê recomendações de calçados, mesmo que esses dados nunca tenham sido acessados no website. Observe que isso exige que você envie um evento de identificação toda vez que o usuário inicia sessão em um dispositivo específico (por exemplo, no celular), para que sempre possamos reconhecer o mesmo usuário em dispositivos diferentes.
Implementação
Receber IDs de usuário e sessão da Dynamic Yield
Há duas maneiras de obter os IDs de usuário e sessão no app:
- Se o usuário for redirecionado do website para o app, os IDs de usuário e sessão devem ser passados juntamente com o redirecionamento e armazenados no app.
- Se o usuário abrir o app sem valores anteriores armazenados, obtenha os IDs chamando uma solicitação vazia /choose e armaze os valores retornados da Dynamic Yield no app.
Armazenar os IDs de usuário e sessão no app
Ambos os valores precisam ser mantidos por diferentes períodos, então cada um é armazenado de forma um pouco diferente:
- Armazene o ID de usuário da Dynamic Yield no app e o mantenha pelo tempo que o app estiver instalado.
- Armazene o ID da sessão da Dynamic Yield no cache do app e o mantenha pelo tempo que o app estiver na memória (primeiro e segundo plano).
Pontos específicos da implementação móvel
Para habilitar o direcionamento de campanhas especificamente para usuários do app, recomendamos que você:
- Implemente um evento personalizado no app logo depois que o usuário receber os IDs de usuário e sessão da Dynamic Yield (por exemplo, um evento com o nome "App User"). Isso permite colocar o usuário em um público exclusivo do app móvel.
- Adicione um atributo personalizado de página a cada solicitação /choose vinda do app. Isso permite o direcionamento da experiência exclusiva do app móvel.
- Gerencie as sessões sem perder o ID do usuário. Quando a sessão no app terminar e o usuário abrir o app novamente, a solicitação /choose para a Dynamic Yield ainda deve incluir o ID de usuário armazenado, mas o valor do ID da sessão deve estar vazio. A resposta da Dynamic Yield conterá o novo ID da sessão que deve ser armazenado no app.
- Adicione os dados de user-agent do app nativo à propriedade userAgent nas chamadas de API. Por exemplo:
- Para iOS: <application-name/1.6.4.176 CFNetwork/897.15 Darwin/17.5.0 (iPhone/6s iOS/11.3)>
- Para Android: <application-name/1.6.7.42 Dalvik/2.1.0 (Linux; U; Android 5.1.1; Android SDK built for x86 Build/LMY48X)
Limitações
Embora usar a mesma seção para a web e app móvel ofereça muitas formas de aprimorar a personalização entre dispositivos, há algumas coisas a se notar se você usar essa abordagem:
- Identificar o usuário tanto na web quanto no app não garante a permanência da variação. A mesma campanha e experiência poderiam ser veiculadas no desktop e app, mas mas não há garantia de que o usuário acessará a mesma variação em ambos os dispositivos devido aos diferentes IDs de usuário e sessão.
- Relatar a localização via URL no app pode ser diferente da web porque não há URLs para buscar no app.
- O relatório de campanhas pode não ser perfeito se você estiver usando campanhas do lado do cliente na web e API no app, porque cada ambiente possui relatórios separados (esse não é o caso se tanto a web quanto o app estiverem usando campanhas por API).
- A alocação em públicos dos usuários que tenham sido identificados com o mesmo ID em dispositivos diferentes acontece de um dia para o outro (funcionalidade padrão).