A correspondência de cookie é um recurso que permite associar seu cookie a exemplo, um ID para um usuário que navegou em seu site, com um ID de usuário do Google específico do bidder e cria listas de usuários que podem ajudar você a tomar opções de lances mais eficientes. Este guia descreve os conceitos usados no Cookie Correspondência, bem como diferentes fluxos de trabalho de correspondência de cookie, e quaisquer variações para certos casos de uso.
Conceitos
O que é a correspondência de cookie?
Os proprietários de domínio normalmente definem o conteúdo de cookies para usuários que navegam seu site, que são usados para identificar os usuários nesse domínio. Mesmo se duas proprietários de domínios concordam em trocar esses dados, o modelo de segurança dos navegadores de internet impede que um leia o cookie definido por outro domínio.
No contexto da publicidade digital, o Google identifica usuários com cookies
que pertencem ao domínio doubleclick.net
, e os bidders
que participam de lances em tempo real podem ter o próprio domínio
identificar algum conjunto de usuários para os quais os anúncios devem aparecer. Correspondência de cookie
permite que o proponente faça a correspondência entre os cookies dele com os do Google
determinam se uma impressão enviada em uma solicitação de lance está associada a um dos
usuários segmentados, eles receberão seus próprios dados de cookies ou uma
ID de usuário do Google específico do bidder, que é uma forma criptografada do
doubleclick.net
na solicitação de lance.
O serviço de correspondência de cookie descrito neste guia facilita a criação e manutenção da associação entre o cookie de um proponente e a rede do User-ID e também permite preencher listas de usuários.
Tabelas de correspondências
Uma tabela de correspondências pode ser usada para mapear um ID ou outros dados de um domínio para o outra. Os bidders podem usar o Serviço de correspondência de cookie para preencher os próprios as tabelas de correspondências mapeando o cookie de um determinado usuário para o serviço do Google User-ID ou para preencher uma tabela de correspondências hospedada pelo Google. As tabelas de correspondências são necessário para que o aplicativo bidder de um bidder acesse os dados de cookies do usuário; a impressão é exibida.
Tabelas de correspondências hospedadas pelo Google
Para facilitar a manutenção, as melhorias na latência e o acesso a dados de correspondência para usuários em determinadas regiões, é recomendável permitir que o Google hospede seu tabela de correspondências. Isso permite que você especifique uma string codificada em base64 segura para a Web: doravante chamados de dados de correspondência hospedados, que serão mapeados para o ID do usuário do Google de um determinado usuário. Uma vez estabelecida uma correspondência, ela pode ser usada das seguintes maneiras:
Lances em tempo real: nas solicitações de lance subsequentes para impressões associados ao usuário, o Google enviará os dados de correspondência hospedados que você correspondentes ao ID de usuário do Google. Se o endpoint de lances estiver configurado para usar o protocolo RTB do Google, você os receberá como bytes decodificados por meio de o campo
BidRequest.hosted_match_data
. No OpenRTB do Google implementação,BidRequest.user.buyeruid
vai retornar dados como uma string codificada em base64 segura para a Web.Listas de usuários: é possível preencher listas de usuários. com IDs de usuários do Google ou dados de correspondência hospedados.
- Pré-segmentação: É possível configurar sua pré-segmentação para receber somente solicitações de lance. que contêm dados de correspondência hospedados. Isso pode ser usado para eliminar impressões para usuários fora do seu espaço de cookie.
Listas de usuários
É possível criar e gerenciar listas de usuários com a API Real-Time Bidding. Depois de criadas, é possível preencher essas listas com os fluxos de trabalho de correspondência de cookie descrito abaixo ou por meio do Serviço de envio em massa.
Primeiros passos
Para começar a usar a correspondência de cookie, você deve entrar em contato com seu Gerente técnico de contas, que pode ativar fluxos de trabalho específicos e ajudar você configure o seguinte:
- ID de rede de correspondência de cookie (NID, na sigla em inglês): um ID de string que identifica exclusivamente uma conta de proponente para a correspondência de cookie e outras operações relacionadas.
- URL de correspondência de cookie: o URL de base de um endpoint que aceitará e processar solicitações recebidas como parte dos fluxos de trabalho de correspondência de cookie. Os bidders podem incorporar macros nesse URL para controlar a ordem dos parâmetros passados para ele nos fluxos de trabalho de correspondência de cookie.
- Match Tag: a tag que você precisa colocar no navegador do usuário para o fluxo de trabalho de correspondência de cookie iniciado pelo bidder. Ela pode ser veiculada junto com anúncios, ou posicionados em propriedades da Web fora dos anúncios.
- URL do relatório de correspondência de cookie (opcional): na coluna Fluxo de trabalho de correspondência de cookie, este é um URL opcional que pode ser fornecido a especifique um endpoint que receberá detalhes do erro caso o cookie a correspondência falha por meio de um redirecionamento HTTP 302. Por padrão, as respostas serão enviado a esse URL se houver um erro na operação de correspondência de cookie, mas o proponente pode solicitar que o redirecionamento sempre seja enviado.
- URL do Assistente de correspondência de cookie: para trocas que implementam o Fluxo de trabalho da assistência de correspondência de cookie, URL de base do endpoint destinado a responder às solicitações de entrada.
- Cota de assistência de correspondência de cookie: para trocas que implementam o Fluxo de trabalho da assistência de correspondência de cookie, número máximo de solicitações que o URL de correspondência de cookie pode receber a cada segundo. Isso evita que as solicitações da CMA sobrecarreguem servidores de troca com solicitações.
Macros de correspondência de cookie
Em qualquer um dos fluxos de trabalho de correspondência de cookie compatíveis, o URL de correspondência de cookie de um proponente normalmente tem parâmetros anexados em um ordenação não garantida. Bidders com integrações que exigem consistência a ordem dos parâmetros podem colocar macros em seu URL de correspondência de cookie para garantir o posicionamento.
Macros com suporte
Os bidders podem configurar o URL de correspondência de cookie deles para incluir um ou
mais macros na forma de %%GOOGLE_<PARAM_NAME>%%
ou
%%GOOGLE_<PARAM_NAME>_PAIR%%
. As macros compatíveis e as
os valores expandidos são:
Macro | Valor ampliado |
---|---|
GOOGLE_GID | GOOGLE_USER_ID |
GOOGLE_GID_PAIR | &google_gid=GOOGLE_USER_ID |
GOOGLE_CVER | COOKIE_VERSION_NUMBER |
GOOGLE_CVER_PAIR | &cver=COOKIE_VERSION_NUMBER |
GOOGLE_ERROR | ERROR_ID |
GOOGLE_ERROR_PAIR | &google_error=ERROR_ID |
GOOGLE_PUSH | PIXEL_MATCH_DATA |
GOOGLE_PUSH_PAIR | &google_push=PIXEL_MATCH_DATA |
GOOGLE_ALL_PARAMS | google_gid=GOOGLE_USER_ID&cver=COOKIE_VERSION_NUMBER&google_error=ERROR_ID |
Exemplo de macro
Um proponente tem uma integração de correspondência de cookie com um endpoint hospedado em
https://user.bidder.com.cookies
, e a implementação deles exige
parâmetros predefinidos definidos pelo bidder, além da correspondência de pixel
na seguinte ordem: google_push
,
google_gid
, google_cver
e
google_error
. O proponente pode fazer isso definindo as
URL de correspondência de cookie para:
https://user.bidder.com/cookies?w=0%%GOOGLE_PUSH_PAIR%%&x=1%%GOOGLE_GID_PAIR%%&y=2%%GOOGLE_CVER_PAIR%%&z=3%%GOOGLE_ERROR_PAIR%%
Quando o Google enviar uma solicitação de correspondência para este bidder, ela será expandida para algo como:
https://user.bidder.com/cookies?w=0&google_push=PUSH_DATA&x=1&google_gid=GOOGLE_GID&y=2&google_cver=1&z=3
Fluxos de trabalho do Serviço de correspondência de cookie
Atualmente, o Serviço de correspondência de cookie do Google é compatível com três fluxos de trabalho para os diferentes casos de uso descritos abaixo.
Iniciada pelo bidder: correspondência de cookie bidirecional
A correspondência de cookie bidirecional se refere a um fluxo de trabalho iniciado pelo bidder, em que o ele coloca uma tag de correspondência no navegador do usuário que a direciona para o Google. Isso permite que o Google e o bidder preencham as tabelas de correspondências. Abaixo está um exemplo simples desse fluxo de trabalho.
Etapa 1: colocar a match tag
Para iniciar esse fluxo, o proponente precisa colocar sua tag de correspondência como renderizado no navegador do usuário. Uma tag de correspondência simples que retorna apenas o ID de usuário do Google ao bidder pode ser estruturado da seguinte maneira:
<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm" />
Há parâmetros adicionais que você pode incluir na tag de correspondência para atender diferentes casos de uso. Para saber mais sobre esses parâmetros, consulte Parâmetros de URL da tag de correspondência.
Etapa 2: o Google responde com redirecionamento, incluindo dados de correspondência
A match tag fará com que o Serviço de correspondência de cookie do Google receba uma
solicitação do navegador do usuário, que emite uma solicitação HTTP 302
redirecionam para o URL de correspondência de cookie do proponente. O redirecionamento incluirá a consulta
parâmetros que especificam o ID de usuário do Google e seu número de versão no URL, e
o bidder também vai receber o cookie incluído nos cabeçalhos da solicitação. Em
prática, para um URL de correspondência de cookie especificado como https://ad.network.com/pixel
,
o URL de redirecionamento da tag de correspondência simples, como visto acima, poderia se parecer com o
seguinte:
https://ad.network.com/pixel?google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1
O ID de usuário do Google transmitido pelo parâmetro google_gid
é
um arquivo codificado em base64 e sem preenchimento seguro para a Web
fio. Para os proponentes que optarem por hospedar uma tabela de correspondências, é recomendado que eles
armazenar a string exata retornada pelo Serviço de correspondência de cookie. Nos próximos
solicitações de lance, ele corresponderá aos valores especificados por meio de BidRequest.google_user_id
no protocolo RTB do Google ou BidRequest.user.id
no
Implementação do OpenRTB.
A versão especificada em google_cver
indica o valor numérico
número da versão do ID de usuário do Google. O ID de usuário do Google para um determinado usuário
serão alterados com pouca frequência e, depois disso, será incrementado.
Se o Google encontrar um erro ao processar sua solicitação de correspondência, uma
O parâmetro google_error
será especificado.
Etapa 3: o bidder processa o redirecionamento e responde com pixels
O bidder recebe um redirecionamento para o URL de correspondência de cookie, incluindo especificados na primeira etapa e os que o Google forneceu na na segunda etapa. Além disso, eles também receberão o cookie no endereço HTTP e cabeçalhos de cache válidos. Se a operação foi bem-sucedida, um proponente hospedando sua própria tabela de correspondências pode corresponder o cookie ao ID de usuário do Google incluído na resposta. É recomendado que os proponentes armazenem a string exata retornada pela ferramenta Serviço.
Se a operação não for bem-sucedida, o bidder vai receber um google_error
.
no redirecionamento. É um valor numérico que corresponde a diferentes
estados de erro que identificam o erro específico que ocorreu. Saiba mais
mais sobre os possíveis valores de erro aqui.
Se receber um erro, você poderá tentar fazer a correspondência com esse usuário novamente
colocar uma nova tag de correspondência.
O proponente precisa sempre responder veiculando uma imagem de pixel invisível de 1 x 1 ou
Você também pode retornar uma resposta HTTP 204
No Content.
Diagrama de fluxo de trabalho da correspondência de cookie
Esse fluxo de trabalho é ilustrado pelo diagrama abaixo, em que as solicitações e as respostas são representadas por uma seta, e os itens de dados que as acompanham estão listadas entre parênteses.
![](https://developers.google.cn/static/authorized-buyers/rtb/images/cookie_matching.png?authuser=7&hl=pt-br)
Parâmetros de URL da Match Tag
Parâmetro | Descrição |
---|---|
google_nid |
É o ID de rede (NID, na sigla em inglês) da conta do bidder. Esse ID pode ser recuperado por meio da interface Bidders recurso. |
google_cm |
Indica ao Serviço de correspondência de cookie do Google que ele deve ter um bom desempenho a correspondência de cookie. O valor do parâmetro é ignorado e pode ser omitido. |
google_sc |
Esse parâmetro foi descontinuado. Define o cookie do Google para o o usuário se ele não estiver presente. O valor do parâmetro é ignorado e pode ser omitida. A omissão do parâmetro resulta em erro se nenhum cookie existe. |
google_no_sc |
Esse parâmetro foi descontinuado. Isso indica para os ao Serviço de correspondência de cookie que não deve definir um cookie para o usuário se um deles não estiver presente. O valor do parâmetro é ignorado e pode ser omitido. |
google_hm |
Dados que o bidder quer armazenar em uma tabela de correspondências hospedada pelo Google.
O valor é uma string codificada em base64 segura para a Web (preenchimento opcional). Os dados brutos devem ser 40
bytes ou menos. Por exemplo, |
google_redir |
É uma string codificada por URL que um bidder pode especificar se quiser direcionar
O Google deve enviar o redirecionamento HTTP 302 ao URL codificado para
nessa tag de correspondência. Isso permite que o Google seja colocado em primeiro plano em um
ou chamadas para parceiros. Isso vai resultar em erro se for especificado sem
google_hm ou com google_cm . |
google_ula |
Uma string usada para adicionar o usuário a uma lista de usuários existente. O valor
o formato esperado é userlistid[,timestamp] :
Esse parâmetro de URL pode ser repetido para adicionar o usuário a vários listas. |
gdpr |
Indica que a solicitação está sujeita a restrições de dados do GDPR
uso. Para obter mais detalhes, consulte
Requisitos de consentimento do usuário da UE abaixo ou Impacto na correspondência de cookie
qualificação no
Documentação do TCF v2.0 do IAB para Authorized Buyers.
Exemplo: |
gdpr_consent |
Uma string de TC que representa o consentimento do usuário final. Para mais detalhes, consulte os requisitos de consentimento para usuários da União Europeia. abaixo ou Como a string de TC será transmitida? na Documentação do TCF v2.0 do IAB para Authorized Buyers. |
process_consent |
Indica que o proponente recebeu o consentimento do usuário final para os usos de dados especificados em
Política de consentimento de usuários da União Europeia do Google.
Se a solicitação não estiver sujeita à Política de consentimento de usuários da União Europeia ou se houver
Há outros parâmetros de consentimento disponíveis na solicitação
( Exemplo: |
Além dos parâmetros acima, os proponentes podem especificar os próprios parâmetros, que
será anexado como parâmetros ao URL de redirecionamento. O valor definido pelo bidder
parâmetros nomeados com o prefixo google_
serão ignorados porque
são reservados pelo Google para desenvolvimento futuro e preservação do
parâmetros a ordenação não é garantida. Uma tag de correspondência, incluindo a definição do bidder
podem ser semelhantes a estes:
<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm&extra1=xx&extra2=yy" />
Parâmetros de URL de redirecionamento
O URL de redirecionamento é criado a partir do URL base de correspondência de cookie configurado para
Conta do bidder, incluindo google_
e parâmetros definidos pelo bidder
dependendo dos especificados na tag de correspondência. Os seguintes google_
parâmetros de resposta forem definidos:
Parâmetro | Descrição |
---|---|
google_gid |
ID do usuário do Google. Definido se google_cm for especificado na solicitação e ela for bem-sucedida. |
google_cver |
Versão do cookie. Definido se google_cm for especificado na solicitação e ela for bem-sucedida. |
google_error |
Um valor inteiro que indica o erro geral de solicitação. Quando
recebida, isso indica que nenhuma operação foi executada, e nenhuma outra
|
google_hm |
Só aparece se a tentativa de gravar na tabela de correspondências hospedada pelo Google falhar. Quando isso acontece, o valor dele é um dos códigos de status a seguir:
|
google_ula |
Status da operação de adição da lista de usuários, repetido se houver vários Por exemplo: A operação
|
Cenários de exemplo do fluxo de trabalho da correspondência de cookie
Os cenários a seguir descrevem como pode ser a correspondência de cookie para um um usuário típico navegando em uma página da Web.
Cenário 1: o usuário limpa os cookies e navega em um site
Jane limpa o cache de todos os cookies. Em seguida, ele visita a página inicial de ExampleNews.com.
Veja o que acontece:
- ExampleNews.com renderiza e chama anúncios do Google (Ad Manager).
- Como o bloco de anúncios está qualificado para a alocação dinâmica, o Google envia o lance solicitações para FinestDSP e outros bidders por meio do serviço de lances em tempo real.
- O aplicativo proponente de FinestDSP recebe e processa a solicitação de lance, e envia sua resposta de lance.
- O Google recebe respostas de lances dos bidders, incluindo a resposta de FinestDSP que especifica um anúncio com uma tag de correspondência (pixel).
- FinestDSP vence o leilão. O Google veicula o anúncio do FinestDSP e a match tag para Jane.
- A match tag chama o Serviço de correspondência de cookie do Google, especificando o
Parâmetros
google_nid
egoogle_cm
. - O Serviço de correspondência de cookie lê o cookie do Google de Jane e envia
um redirecionamento para o URL de correspondência de cookie de FinestDSP com o
Os parâmetros
google_user_id
egoogle_cver
foram definidos. - O navegador de Jane carrega o redirecionamento para o URL de correspondência de cookie de FinestDSP.
- O endpoint de correspondência de cookie de FinestDSP processa a solicitação de redirecionamento,
que inclui parâmetros de URL definidos pelo Google e o cookie para Jane na
cabeçalhos HTTP. FinestDSP agora pode armazenar o mapeamento de seu cookie para o
google_user_id
na tabela de correspondências. - FinestDSP responde ao redirecionamento com um pixel 1 x 1 invisível.
![](https://developers.google.cn/static/authorized-buyers/rtb/images/cookie-matching-schematic.png?authuser=7&hl=pt-br)
Cenário 2: usuário com mapeamento existente
Uma semana após o Cenário 1, Jane visita ExampleNews.com novamente. Agora que Jane tiver cookies do bidder e do Ad Manager na máquina, veja como a correspondência funciona.
- A página da Web é renderizada, fazendo com que o Google (Ad Manager) solicite anúncios que serão renderizados na página.
- Durante o leilão de anúncios, o Google envia uma solicitação de lance para os bidders aplicáveis. incluindo FinestDSP.
- FinestDSP recebe a solicitação de lance, incluindo sinais como o
google_user_id
: - FinestDSP pesquisa
google_user_id
na tabela de correspondências, e encontra o cookie associado a Jane que foi criado uma semana antes (no cenário 1). - Com base nas informações associadas ao cookie, os lances de FinestDSP lógica dá um lance na impressão e vence o leilão.
- Jane pode ver um anúncio personalizado de acordo com os interesses dela com base em informações que FinestDSP possui.
Iniciada pelo bidder: correspondência unidirecional de cookie
A correspondência unidirecional de cookie é semelhante ao fluxo de trabalho bidirecional,
mas alterado de forma que somente o Google hospede e preencha uma correspondência
tabela. Isso pode ser usado nos casos em que o proponente não tem permissão para hospedar
IDs de usuários do Google na própria tabela de correspondências. Para usar esse fluxo, os proponentes
precisa permitir que o Google hospede a tabela de correspondências, não é mais possível especificar
google_cm
em solicitações para o Serviço de correspondência de cookie do Google e
Consequentemente, não receberão google_gid
para preencher as próprias
tabela de correspondências. Depois que o Google estabelece uma correspondência para um usuário, os bidders podem adicionar
às listas de usuários usando seus próprios dados de cookies. Da mesma forma, as solicitações de lance
esses usuários excluem o ID de usuário do Google, mas incluem dados de correspondência hospedados. Um
um exemplo simples do fluxo de trabalho revisado é resumido nas etapas abaixo.
Etapa 1: coloque a match tag direcionada ao URL de correspondência de cookie do bidder
Para iniciar esse fluxo, um proponente precisa inserir uma tag de correspondência de modo que
é renderizado no navegador do usuário. Ao contrário do fluxo de trabalho
para usuários de fora dos EUA com restrições de privacidade,
a tag de correspondência deve direcionar o navegador do usuário para o seu Cookie
URL correspondente. Por exemplo, com um URL de correspondência de cookie configurado como
https://ad.network.com/pixel
, teria esta aparência:
<img src="https://ad.network.com/pixel" />
Ao carregar no navegador do usuário, ele solicita um pixel do atributo URL de correspondência de cookie. Essa solicitação conterá o cookie no cabeçalho HTTP, que deve ser extraído para a próxima etapa.
Etapa 2: redirecionar para o serviço de correspondência de cookie do Google
O endpoint de correspondência de cookie do bidder precisa redirecionar para o cookie do Google
Serviço correspondente, incluindo o parâmetro google_hm
preenchido com
os dados de cookies codificados em base64 seguros para a Web. O URL de redirecionamento pode ser semelhante ao
seguinte:
https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_hm=HOSTED_MATCH_DATA
Etapa 3: o navegador do usuário é redirecionado para o serviço de correspondência de cookie do Google
O Google receberá um redirecionamento contendo os parâmetros especificados, em além do cookie do Google nos cabeçalhos HTTP.
Etapa 4: o Google veicula o pixel em caso de sucesso ou erro de redirecionamento se o URL do relatório for especificado
Se a operação de correspondência de cookie for bem-sucedida ou se nenhum valor
O URL do relatório correspondente foi especificado na conta do bidder: Google
exibirá um pixel transparente de 1 x 1 por padrão, e o fluxo de trabalho terminará aqui.
As impressões desse usuário nas solicitações de lance subsequentes incluirão os valores do bidder
dados de correspondência hospedados em BidRequest.hosted_match_data
para o Google
protocolo, ou BidRequest.user.buyeruid
para OpenRTB do Google
implementação. Os bidders também podem preencher listas de usuários usando os dados de correspondência hospedados
especificados.
Caso contrário, se ocorrer um erro, o Google vai enviar um redirecionamento para a conta de
URL do Relatório de correspondência de cookie com a causa do erro especificado no
parâmetro google_error
. Se o URL do relatório de correspondência de cookie do bidder
for https://ad.network.com/report
, o URL de redirecionamento será
como:
<img src="https://ad.network.com/report?google_error=ERROR_ID" />
Etapa 5: o navegador do usuário redireciona para o URL do relatório de correspondência de cookie do bidder
O navegador do usuário vai redirecionar para o URL do Relatório de correspondência de cookie do bidder
incluindo o motivo do erro (se houver) especificado pelo Google no
parâmetro google_error
. Para saber mais sobre como interpretar o erro
, consulte a descrição do parâmetro.
Etapa 6: o proponente veicula um pixel transparente de 1 x 1
O proponente precisa responder veiculando um pixel transparente de 1 x 1 ao objeto navegador.
Diagrama de fluxo de trabalho da correspondência de cookie para usuários de estados dos EUA com restrições de privacidade
O fluxo de trabalho padrão para usuários nos estados dos EUA com restrições de privacidade é ilustrado pelo diagrama abaixo, onde as solicitações e respostas são representadas por uma seta, e os dados os itens que os acompanham são listados entre parênteses.
![](https://developers.google.cn/static/authorized-buyers/rtb/images/cookie_matching_ca.png?authuser=7&hl=pt-br)
Parâmetros de URL do redirecionamento do bidder para o serviço de correspondência de cookie do Google
Parâmetro | Descrição |
---|---|
google_nid |
É o ID de rede (NID, na sigla em inglês) da conta do bidder. Esse ID pode ser recuperado por meio da interface Bidders recurso. |
google_sc |
Esse parâmetro foi descontinuado. Define o cookie do Google para o o usuário se ele não estiver presente. O valor do parâmetro é ignorado e pode ser omitida. A omissão do parâmetro resulta em erro se nenhum cookie existe. |
google_no_sc |
Esse parâmetro foi descontinuado. Isso indica para os ao Serviço de correspondência de cookie que não deve definir um cookie para o usuário se um deles não estiver presente. O valor do parâmetro é ignorado e pode ser omitido. |
google_hm |
Contém dados que o bidder quer armazenar em uma correspondência hospedada pelo Google. tabela. |
google_redir |
Um URL codificado para o qual você quer que o Google envie um redirecionamento HTTP 302. A
o URL especificado vai receber redirecionamentos com google_error
para erros e operações bem-sucedidas. |
google_ula |
Uma string usada para adicionar o usuário a uma lista de usuários existente. O valor
o formato esperado é userlistid[,timestamp] :
Esse parâmetro de URL pode ser repetido para adicionar o usuário a vários listas. |
gdpr |
Indica que a solicitação está sujeita a restrições de dados do GDPR
uso. Para obter mais detalhes, consulte
Requisitos de consentimento do usuário da UE abaixo ou Impacto na correspondência de cookie
qualificação no
Documentação do TCF v2.0 do IAB para Authorized Buyers.
Exemplo: |
gdpr_consent |
Uma string de TC que representa o consentimento do usuário final. Para mais detalhes, consulte os requisitos de consentimento para usuários da União Europeia. abaixo ou Como a string de TC será transmitida? na Documentação do TCF v2.0 do IAB para Authorized Buyers. |
process_consent |
Indica que o proponente recebeu o consentimento do usuário final para os usos de dados especificados em
Política de consentimento de usuários da União Europeia do Google.
Se a solicitação não estiver sujeita à Política de consentimento de usuários da União Europeia ou se houver
Há outros parâmetros de consentimento disponíveis na solicitação
( Exemplo: |
Os parâmetros de URL do redirecionamento do Google para o URL do Relatório de correspondência de cookie do bidder
Parâmetro | Descrição |
---|---|
google_error |
Um valor inteiro que indica o erro geral de solicitação. Quando
recebida, isso indica que nenhuma operação foi executada, e nenhuma outra
|
Iniciada pelo Google: correspondência bidirecional de pixels
A correspondência bidirecional de pixels é um fluxo de trabalho para a correspondência de cookie do Google Serviço em que o Google tenta corresponder um ID de usuário do Google a um o proponente selecionado que não seja o vencedor do leilão de lances em tempo real. Quando um anúncio é colocado, o Google colocará uma match tag direcionando o navegador do usuário para carregar uma pixel transparente do URL de correspondência de cookie do proponente escolhido. Isso permitirá o Google e o bidder preenchem uma tabela de correspondências com um determinado usuário. Abaixo está um exemplo simples desse fluxo de trabalho.
Etapa 1: o Google coloca uma tag de correspondência
Quando a página de um editor participante é carregada no navegador do usuário, e um
espaço de anúncio nessa página é preenchido pelo Google, uma tag de correspondência pode ser colocada que
solicita um pixel de um bidder selecionado com base em algoritmos. A correspondência de pixel
colocada pelo Google combina o URL de correspondência de cookie do bidder com
parâmetros adicionais o
que o proponente pode usar para preencher a tabela de correspondências. Para um URL de correspondência de cookie
especificado como https://ad.network.com/pixel
, ele é estruturado como
da seguinte forma:
<img src="https://ad.network.com/pixel?google_gid=GOOGLE_GID&google_cver=1&google_push=PUSH_DATA" />
Etapa 2: o bidder precisa responder com redirecionamento para o URL do Serviço de correspondência de cookie do Google
Os bidders que recebem solicitações de correspondência de pixel precisam responder com uma redirecionam para o Serviço de correspondência de cookie do Google, estruturado da seguinte maneira:
https://cm.g.doubleclick.net/pixel?google_nid=GOOGLE_NID&google_push=PUSH_DATA
O URL de redirecionamento acima é semelhante ao URL usado no campo
tag de correspondência para o fluxo de trabalho de correspondência de cookie iniciado pelo bidder.
Na correspondência de pixel, o parâmetro google_cm
é substituído pelo
parâmetro google_push
, e o valor dele precisa ser igual ao valor
fornecido pelo Google na solicitação. Também semelhante ao modo iniciado pelo bidder
fluxo de trabalho, parâmetros adicionais
podem ser especificadas para atender
a outros casos de uso.
Etapa 3: o Google processa o redirecionamento e responde com pixel
O Google registra que uma correspondência foi criada para o usuário e processa qualquer operações adicionais solicitadas por meio de parâmetros de consulta. Por fim, o Google responde com um pixel transparente de 1 x 1.
Diagrama do fluxo de trabalho da correspondência de pixel
Esse fluxo de trabalho é ilustrado pelo diagrama abaixo, em que as solicitações e as respostas são representadas por uma seta, e os itens de dados que as acompanham estão listadas entre parênteses.
![](https://developers.google.cn/static/authorized-buyers/rtb/images/pixel_matching.png?authuser=7&hl=pt-br)
Parâmetros de solicitação da tag de correspondência do Google
Parâmetro | Descrição |
---|---|
google_gid |
ID do usuário do Google. Para usuários de fora de um estado dos EUA com restrições de privacidade, isso sempre será especificado na match tag do Google. |
google_cver |
A versão do cookie. Sempre será especificado na correspondência do Google tag. |
google_push |
Indica que essa solicitação está iniciando o fluxo de trabalho de correspondência de pixel. O valor precisa ser retornado pelo parâmetro correspondente na resposta de redirecionamento. |
Parâmetros de redirecionamento da correspondência de pixel do bidder
Parâmetro | Descrição |
---|---|
google_nid |
É o ID de rede (NID, na sigla em inglês) da conta do bidder. Esse ID pode ser recuperado por meio da interface Bidders recurso. |
google_push |
Indica que esse redirecionamento está concluindo a correspondência de pixel de desenvolvimento de software. O valor da tag de correspondência do Google correspondente precisa ser especificado aqui. |
google_hm |
Contém dados que o bidder quer armazenar em uma correspondência hospedada pelo Google. tabela. |
google_ula |
Uma string usada para adicionar o usuário a uma lista de usuários existente. O valor
o formato esperado é userlistid[,timestamp] :
Esse parâmetro de URL pode ser repetido para adicionar o usuário a vários listas. |
Iniciada pelo Google: correspondência unidirecional de pixels
A correspondência unidirecional de pixels é diferente do fluxo de trabalho bidirecional no que a tag de correspondência do Google não inclua um parâmetro que especifique a propriedade mas continuará a preencher uma tabela de correspondências hospedada pelo Google. Isso pode ser usado nos casos em que o proponente não tem permissão para hospedar IDs de usuário do Google na sua tabela de correspondências. Um exemplo simples do fluxo de trabalho revisado é resumido etapas abaixo.
Etapa 1: o Google coloca uma tag de correspondência
O Google coloca uma tag de correspondência para um bidder selecionado por algoritmos. A match tag inclui o
parâmetro google_push
. Veja um exemplo:
<img src="https://ad.network.com/pixel?google_push=PUSH_DATA" />
Etapa 2: o navegador do usuário solicita o pixel do URL de correspondência de culinária do bidder
O navegador do usuário solicita um pixel do URL de correspondência de cookie do bidder incluindo o cookie do proponente nos cabeçalhos HTTP.
Etapa 3: redirecionar para o Serviço de correspondência de cookie do Google
O endpoint de correspondência de cookie do bidder precisa redirecionar para o cookie do Google
Serviço correspondente, incluindo o parâmetro google_hm
preenchido com
os dados de cookies codificados em base64 seguros para a Web. O URL de redirecionamento pode ser semelhante ao
seguinte:
https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_hm=HOSTED_MATCH_DATA&google_push=PUSH_DATA
Etapa 4: o navegador do usuário é redirecionado para o serviço de correspondência de cookie do Google
O Google receberá um redirecionamento contendo os parâmetros especificados, em
além do cookie do Google nos cabeçalhos HTTP. Se a operação foi
bem-sucedidas, as impressões desse usuário nas solicitações de lance subsequentes incluirão
os dados de correspondência hospedados pelo bidder em BidRequest.hosted_match_data
para
o Protocolo do Google, ou BidRequest.user.buyeruid
para
Implementação do OpenRTB. Os proponentes também podem preencher listas de usuários usando o
corresponder aos dados especificados.
Por fim, o Google retorna um pixel transparente de 1 x 1 para o navegador do usuário.
Assistente de correspondência de cookie
O Open Bidding permite que as trocas usem lances iniciados pelo bidder e iniciados pelo Google fluxos de trabalho de correspondência de cookie, para fazer a correspondência entre um ID de usuário do Google e seu cookie. Biscoito O Assistente de correspondência (CMA) é um recurso adicional para trocas que permite criar tabelas de correspondências com seus próprios proponentes.
Como o Assistente de correspondência de cookie funciona
Ao posicionar um anúncio, o Google seleciona algoritmo participante e coloca uma tag de assistência de correspondência de cookie com a seguinte estrutura:
<img src="https://ob.exchange.com/pixel?google_gid=GOOGLE_GID&google_cver=1"/>
A tag de correspondência CMA do Google faz com que o URL de correspondência de cookie da troca recebem uma solicitação de pixel.
- O endpoint de correspondência de cookie da troca recebe a solicitação, em que seu próprio serviço de correspondência de cookie é responsável por corresponder o ID do usuário com para um de seus proponentes. No diagrama abaixo, a correspondência de cookie da troca responde ao navegador do usuário com um redirecionamento para um dos endpoints.
- O proponente recebe a solicitação, com todos os parâmetros especificados por na troca para fazer a correspondência entre o ID do usuário e o cookie.
![](https://developers.google.cn/static/authorized-buyers/rtb/images/cookie_match_assist_diagram.png?authuser=7&hl=pt-br)
Restrições
Limitar a frequência das solicitações para novas correspondências
Os proponentes são responsáveis por limitar o número de chamadas para o Serviço de Serviço de correspondência para usuários que têm uma nova entrada na correspondência hospedada pelo Google tabela. Uma entrada na tabela de correspondências hospedada pode ser considerada expirada em 14 dias, Depois disso, ele poderá ser atualizado.
Responder a todas as solicitações de correspondência de pixel
Os bidders que usam o fluxo de trabalho de correspondência de pixel devem responder a todas
solicitações recebidas do Pixel Match com uma resposta que inclua o google_push
. Isso permite que o Google monitore o uso para aplicar políticas. Se um
a taxa de resposta do proponente cair para menos de 90%, o Google limitará o número de
solicitações de correspondência de pixel enviadas para a conta dele;
Usar endpoints HTTPS
É obrigatório que os endpoints usados em todos os fluxos de trabalho de correspondência de cookie usem HTTPS.
Ao responder a uma solicitação de correspondência de pixel enviada a você por HTTPS, você está: necessário redirecionar para o Serviço de correspondência de cookie por HTTPS. Da mesma forma, um endpoint do Assistente de correspondência de cookie que redireciona para proponentes também precisa usar HTTPS. Se você envia solicitações ao Google por HTTP mais de uma vez a cada dois minutos, o número de solicitações de correspondência enviadas para sua conta será limitado.
Requisitos de consentimento dos usuários da UE
Solicitações de correspondência de cookie que estão sujeitas a Usuário da UE do Google A política de consentimento precisa indicar o consentimento do usuário final. Essas solicitações são obrigatórias para indicar que o consentimento foi obtido de uma das seguintes maneiras:
- TCF v2: inclui
gdpr
egdpr_consent
parâmetros. Para mais detalhes, consulte o Documentação do TCF v2.0 do IAB para Authorized Buyers. process_consent
: uma declaração de que o bidder recebeu o consentimento necessário do usuário.
Exemplos
Os exemplos abaixo ilustram como usar o Serviço de correspondência de cookie para e alcançar objetivos específicos. A menos que seja indicado o contrário, é presumido que o usuário que está recebendo uma ação não se origina Estado dos EUA com restrições de privacidade.
Preencher uma tabela de correspondências hospedada pelo bidder
Um bidder pode usar o fluxo de trabalho de correspondência de cookie para preencher a própria correspondência
da tabela fornecendo apenas o google_nid
e o google_cm
nas tags de correspondência. O resultado será algo como o seguinte:
<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_cm" />
Se o URL de correspondência de cookie do bidder estiver definido como https://ad.network.com/pixel?id=1
,
e a operação de correspondência de cookie for bem-sucedida, o redirecionamento que o Google envia
resposta à tag de correspondência do proponente pode ser semelhante a esta:
https://ad.network.com/pixel?id=1&google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1
Se a operação de correspondência de cookie falhar porque o usuário não tem uma cookie do Google, a resposta será:
https://ad.network.com/pixel?id=1&google_error=3
O código do erro depende da causa subjacente. Para saber mais sobre possíveis códigos de erro para o fluxo de trabalho da Correspondência de cookie, consulte a parâmetros de URL de redirecionamento.
Adicionar à lista de usuários únicos
O parâmetro google_ula
pode ser especificado na correspondência de um bidder
para adicionar o usuário a uma lista de usuários com o ID fornecido. Se o serviço do Google
a tabela de correspondências hospedada pelo bidder tiver uma nova entrada para o usuário, ele poderá
uma tag de correspondência incluindo google_nid
e google_ula
para adicionar o usuário à lista especificada sem iniciar a
Fluxo de trabalho de correspondência de cookie. Veja as restrições
invocar o Serviço de correspondência de cookie para mais falhas. O modelo
tag de correspondência poderá ser semelhante a:
<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345" />
Para uma resposta bem-sucedida, quando o URL de correspondência de cookie do bidder for
https://ad.network.com/pixel
, o URL de redirecionamento do Google será:
https://ad.network.com/pixel?google_ula=12345,0
Se houver um erro geral, por exemplo, não houver cookie do Google
para o usuário, o URL de redirecionamento incluirá o elemento
Parâmetro google_error
:
https://ad.network.com/pixel?google_error=3
Se houver um erro especificamente relacionado à adição do usuário à lista,
você vai receber google_ula
no redirecionamento. Ao contrário do
o parâmetro da tag de correspondência correspondente, ele substitui o carimbo de data/hora por um valor
para indicar o sucesso da operação. Por exemplo, se a solicitação falhar
porque a conta do proponente não tinha acesso à lista de usuários especificada, o
URL de redirecionamento será:
https://ad.network.com/pixel?google_ula=12345,2
Adicionar a várias listas de usuários
Os bidders podem especificar que um usuário precisa ser adicionado a várias listas de usuários
incluindo vários parâmetros google_ula
na tag de correspondência. Em
prática, o resultado será semelhante a este:
<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345,7654321&google_ula=45678" />
O status da operação de cada lista de usuários é informado de forma semelhante pelo
parâmetros google_ula
distintos no redirecionamento:
https://ad.network.com/pixel?google_ula=12345,2&google_ula=45678,0
No redirecionamento acima, podemos ver que a operação foi bem-sucedida para o usuário
lista com o ID 45678
, mas ocorreu uma falha para o ID da lista de usuários 12345
porque o bidder não tinha permissão para acessá-lo.
Seguir o fluxo de trabalho da correspondência de cookie e adicionar à lista de usuários
Para realizar a correspondência de cookie e adicionar o usuário a uma lista de usuários em um único
solicitação, a tag de correspondência de um proponente deverá incluir google_cm
e
google_ula
:
<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345&google_cm" />
O URL de redirecionamento especificado pelo Google incluiria google_gid
,
google_cver
e google_ula
. Ela pode parecer com a
seguinte:
https://ad.network.com/pixel?id=&google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1&google_ula=12345,0
Armazenar uma correspondência em uma tabela de correspondências hospedada pelo Google
Se um bidder quiser armazenar os dados de cookies em uma tabela de correspondências hospedada pelo Google,
e não pretende armazenar a correspondência com o ID de usuário do Google na sua própria correspondência
tabela, a tag de correspondência deve incluir o parâmetro google_hm
, em que
o valor dele precisa ser uma string codificada em base64 segura para a Web. Para um usuário em que o
os dados de cookies não codificados do bidder são Cookie number 1!
, o valor codificado
valor seria Q29va2llIG51bWJlciAxIQ==
, que seria usado em uma
de correspondência de tag da seguinte forma:
<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D" />
Para uma resposta bem-sucedida, quando o URL de correspondência de cookie do bidder for
https://cookie-monster.com/pixel
, o URL de redirecionamento do Google
ser:
https://cookie-monster.com/pixel
O parâmetro google_gid
não está no redirecionamento porque o
tag de correspondência não incluiu google_cm
, e google_hm
está
ou não incluídas em respostas bem-sucedidas. Em futuras solicitações de lance para impressões
para este usuário, o proponente receberá os dados de correspondência hospedados dele em
BidRequest.hosted_match_data
para o protocolo RTB do Google; ou
BidRequest.user.buyeruid
para a implementação do OpenRTB do Google.
Se o proponente usasse uma tag de correspondência em que o valor de
google_hm
não foi codificado em base64, como
chocolate_chunk!
: o URL de redirecionamento pode ser semelhante ao
seguinte:
https://cookie-monster.com/pixel?google_hm=2
O URL de redirecionamento acima inclui um valor google_hm
de
2
, sugerindo que a operação falhou porque o valor poderia
não será decodificado.
Tabelas de correspondências hospedadas pelo Google e pelo bidder com listas de usuários
Se um bidder hospeda a própria lista de uso, além de um usuário hospedado pelo Google
lista e quer que uma única tag de correspondência combine as duas tabelas e adicione o usuário a uma
de acordo com a lista de usuários, a tag de correspondência precisa incluir google_cm
,
parâmetros google_hm
e google_ula
. Se o método
os dados de cookies forem Cookie number 1!
, o valor codificado será
Q29va2llIG51bWJlciAxIQ==
, que produziria uma tag de correspondência como a
seguinte:
<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D&google_cm&google_ula=12345" />
Para uma resposta bem-sucedida, quando o URL de correspondência de cookie do bidder for
https://cookie-monster.com/pixel
, o URL de redirecionamento do Google
será assim:
https://cookie-monster.com/pixel?google_gid=ABCDETC&google_cver=1&google_ula=12345,0
Ao receber o redirecionamento, o bidder pode corresponder ao ID de usuário do Google especificado.
em google_gid
com os dados de cookies na tabela de correspondências. Em
Além disso, ele pode determinar que a tabela de correspondências hospedada pelo Google e a lista de usuários
as operações foram bem-sucedidas. Como consequência, toda pré-segmentação do proponente
configurada para segmentar o ID da lista de usuários especificado, isso vai fazer com que o bidder
receber solicitações de lance para impressões do usuário. Da mesma forma, nesses lances
solicitações, o proponente receberá seus dados de correspondência hospedados em
BidRequest.hosted_match_data
para o protocolo RTB do Google; ou
BidRequest.user.buyeruid
para a implementação do OpenRTB do Google.