Uma linha no template e o catálogo por feed. Em operação de grande varejo, o mK Fashion+ adiciona ao carrinho pelo mesmo formulário autenticado que a loja usa, respeitando o token de segurança da plataforma, e reconstrói o mini-cart do cabeçalho para o cliente ver que a peça entrou.
No <head> do template base da loja, em todas as páginas.
<script src="https://unpkg.com/mk-sdk-git@1/dist/mk-sdk.js"
data-mk-project="SEU_PROJECT_ID"
data-mk-product="mk-fashion"
async></script>Troque SEU_PROJECT_ID pelo identificador do seu projeto. O atributo async garante que a tag não bloqueia o carregamento da página, e @1 fixa a major da versão: você recebe correção sem risco de um release novo mudar a loja sem aviso.
A metaKosmos cria o projeto e envia o identificador. Ele é o único valor que muda na tag, e não é segredo: vai no HTML público da loja.
Em vez de abrir acesso à API corporativa, o catálogo entra pelo feed no padrão do Merchant Center que a operação já mantém. É o caminho de menor atrito com a área de segurança: nenhuma credencial nova, nenhum acesso a sistema interno.
A tag precisa valer em todas as páginas, não só na de produto: é assim que o funil inteiro, da visita à compra, é medido. Se a operação usa gerenciador de tags, configure o disparo para todas as páginas.
Operação deste porte tem ambiente de homologação, e é onde confirmamos o ciclo inteiro: identificação do produto, seleção de tamanho, adição ao carrinho e atualização do mini-cart do cabeçalho.
Em operação de grande varejo, liberar acesso a sistema interno é um projeto à parte, com segurança e jurídico envolvidos. O catálogo entra pelo feed do Merchant Center que a operação já publica, então a integração começa sem esse caminho crítico.
A plataforma protege o carrinho com um token de segurança por sessão. O adapter lê esse token do formulário da própria página e o envia junto, então a adição é indistinguível da que a loja faria e não contorna nenhuma proteção.
Cada tamanho carrega o código da própria variante no elemento de seleção. O adapter usa esse código, e não uma correspondência por texto, então a peça que entra no carrinho é exatamente a escolhida no provador.
O mecanismo nativo de atualizar o mini-cart não funciona em toda implantação, e o conteúdo do menu fica preso no estado do carregamento da página, mostrando carrinho vazio com item dentro. O SDK busca o fragmento fresco do carrinho e reconstrói o menu, o contador e o total.
A resposta da adição pode vir com o total em branco. O valor autoritativo é buscado do fragmento de carrinho da própria loja, então o dado de valor que chega ao painel é o que o cliente vê na tela.
Além da web, existe um SDK React Native que leva o provador e a medição para o app da operação, com o provador em WebView e o SKU informado pela tela, já que ali não há página para ler.
A integração tem duas metades, e em operação de grande varejo elas têm donos diferentes dentro da empresa.
O catálogo entra por feed, no padrão do Merchant Center, que a operação já mantém para anunciar. Foi uma escolha deliberada: pedir acesso à interface de programação de uma plataforma corporativa transforma a integração num projeto de segurança antes de ser um projeto de produto. Com o feed, o provador começa a funcionar enquanto esse acesso, se for desejado, corre em paralelo.
A loja é a tag no template. Ela roda no navegador do cliente final, identifica o produto pela URL, injeta o botão e adiciona ao carrinho pelo formulário autenticado da própria loja.
A plataforma protege as operações de carrinho com um token por sessão, e é uma proteção legítima contra requisição forjada de outro site.
O adapter não a contorna. Ele lê o token do formulário que já está na página, o mesmo que a loja enviaria, e o inclui na adição. O resultado é que a requisição é idêntica à nativa aos olhos do servidor, e nenhuma exceção de segurança precisa ser aberta para o provador funcionar.
Vale para o código da peça também: cada opção de tamanho carrega o código da variante no próprio elemento, e é ele que vai na adição, em vez de uma correspondência por texto que quebraria com mudança de rótulo.
Este é o problema que mais custa conversão e o menos óbvio de todos. Quando a adição acontece por interface de programação, o contador do cabeçalho não se mexe, porque ele só reage à adição nativa.
Pior: o conteúdo do menu de carrinho fica preso no estado do carregamento da página. O cliente adiciona pelo provador, abre o menu e lê carrinho vazio, com a peça dentro do carrinho de verdade. Ele conclui que não funcionou.
O mecanismo nativo de atualização também não resolve em toda implantação, porque depende de elementos que nem todo tema tem. Então o SDK busca o fragmento de carrinho da própria loja, já renderizado e fresco, e com ele reconstrói o conteúdo do menu, o contador e o total. Preservando o elemento que o tema usa para o gatilho de abertura, para não quebrar o comportamento dele.
Operação deste porte costuma ter aplicativo próprio, e o provador precisa existir nos dois lugares para a comparação de resultado fazer sentido.
Na web é a tag, que lê a página. No aplicativo é um SDK React Native separado: o provador abre em WebView e a integração é explícita, com a tela informando qual peça está aberta, já que ali não existe página para o SDK ler. A medição de jornada é a mesma nos dois, então o funil do app e o do site ficam no mesmo painel.
Sim, com módulo dedicado. A adição usa o formulário autenticado da própria loja, respeitando o token de segurança da plataforma, e o mini-cart do cabeçalho é reconstruído depois de adicionar.
Não. O catálogo entra pelo feed no padrão do Merchant Center que a operação já mantém. Abrir acesso à interface de programação corporativa é um projeto de segurança à parte, e a integração não depende dele para começar.
Não. O token de segurança por sessão é lido do formulário que já está na página e enviado junto, então a requisição é idêntica à que a própria loja faria.
Sim. Como a adição é por interface de programação, o contador não se atualizaria sozinho, então o SDK busca o fragmento de carrinho da loja e reconstrói o menu, o contador e o total.
Sim, um SDK React Native com o provador em WebView e integração explícita, já que num app não há página para o SDK ler. A medição de jornada é a mesma da web.
Pelo código de produto que aparece na URL da página. O marcador de SKU da plataforma expõe um código interno diferente, que o catálogo do provador não conhece, e por isso não é usado.