O widget empurra cada evento na camada de dados (dataLayer) da sua página. Não é preciso instalar nada a mais: se o GTM está no site, ele já está recebendo.
São dez eventos, com o nome sempre começando em floatvideo_:
| Nome do evento | Quando acontece |
|---|---|
floatvideo_impression |
O balão apareceu |
floatvideo_expand |
A pessoa tocou e o vídeo abriu |
floatvideo_play |
O vídeo começou a tocar |
floatvideo_progress_3s |
Passou dos três segundos |
floatvideo_progress_25 |
Um quarto do vídeo |
floatvideo_progress_50 |
Metade |
floatvideo_progress_75 |
Três quartos |
floatvideo_complete |
Assistiu até o fim |
floatvideo_cta_click |
Concluiu a ação do botão |
floatvideo_close |
Fechou o balão |
Junto de cada evento vai um objeto floatvideo com o identificador do widget, o endereço da página e qual vídeo estava no ar. No floatvideo_cta_click vão também cta_type (o tipo de botão) e cta_label (o texto dele).
No floatvideo_cta_click de formulário vai mais uma coisa: um user_data com o e-mail e o telefone de quem preencheu, já normalizados e convertidos em hash SHA-256, nas chaves sha256_email_address e sha256_phone_number. É o formato que o Google espera para dado que já chega protegido, e é o que permite a conversão otimizada (ver 8.5 e 8.9).
Os campos preenchidos nunca entram na camada de dados em texto legível. A camada de dados é visível para qualquer script da página, e o hash resolve o impasse: serve para o Google e o Meta casarem a conversão, e não serve para ninguém ler.
Duas coisas que costumam pegar quem está montando:
Os campos do formulário não são alcançáveis por seletor de CSS. O balão vive isolado do resto da página (Shadow DOM), justamente para o visual do seu site não afetar o dele. Isso significa que nenhuma variável do tipo “elemento do DOM” chega nos campos. Quem quiser o e-mail ou o telefone usa o user_data acima.
O hash só existe em página segura (https). Em http o evento sai sem o user_data, em vez de sair com os dados em texto.