Correspondência de cookie

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:

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.

Parâmetros de URL da Match Tag

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:

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:

1. ExampleNews.com renderiza e chama anúncios do Google (Ad Manager).
2. 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.
3. O aplicativo proponente de FinestDSP recebe e processa a solicitação de lance, e envia sua resposta de lance.
4. 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).
5. FinestDSP vence o leilão. O Google veicula o anúncio do FinestDSP e a match tag para Jane.
6. A match tag chama o Serviço de correspondência de cookie do Google, especificando o Parâmetros google_nid e google_cm.
7. 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 e google_cver foram definidos.
8. O navegador de Jane carrega o redirecionamento para o URL de correspondência de cookie de FinestDSP.
9. 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.
10. FinestDSP responde ao redirecionamento com um pixel 1 x 1 invisível.

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.

1. A página da Web é renderizada, fazendo com que o Google (Ad Manager) solicite anúncios que serão renderizados na página.
2. Durante o leilão de anúncios, o Google envia uma solicitação de lance para os bidders aplicáveis. incluindo FinestDSP.
3. FinestDSP recebe a solicitação de lance, incluindo sinais como o google_user_id:
4. 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).
5. 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.
6. 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.

Parâmetros de URL do redirecionamento do bidder para o serviço de correspondência de cookie do Google

Os parâmetros de URL do redirecionamento do Google para o URL do Relatório de correspondência de cookie do bidder

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.

Parâmetros de solicitação da tag de correspondência do Google

Parâmetros de redirecionamento da correspondência de pixel do bidder

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

1. 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"/>

2. 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.

3. 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.
4. 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.

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 e gdpr_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.