O catálogo entra por app instalado na loja, com OAuth e token renovado sozinho. Na página de produto, o provador identifica a peça pelos dados estruturados que a Tray já publica e aciona o botão de compra do próprio tema. Sem plugin e sem reescrever o template.
No <head> do tema 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.
O app da metaKosmos na Tray autoriza a leitura do catálogo e importa produtos, variações, preços e imagens. A autorização se renova sozinha, então a conexão não cai depois de alguns dias e ninguém precisa reautorizar.
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 sua operação usa gerenciador de tags, configure o disparo para todas as páginas.
Com o projeto configurado, o botão de provar aparece ao lado do comprar, nos produtos que têm provador. Abra o provador, escolha um tamanho, adicione e confira o item na sacola.
O app instalado na loja autoriza a leitura do catálogo e a metaKosmos renova a autorização sozinha antes de ela expirar. A conexão não cai sozinha depois de alguns dias, que é o problema clássico desse tipo de integração.
A importação traz o catálogo com as variações e os preços, então o provador sabe a grade real de cada peça em vez de mostrar tamanhos genéricos.
Um app a autorizar e uma linha no tema. Nenhum arquivo de template é reescrito e nenhum componente novo entra na página de produto.
O botão de provar é injetado em Shadow DOM fechado, ancorado ao lado do comprar, com aparência controlada pelo painel. O CSS da loja e o nosso ficam isolados.
Visita, produto, carrinho e compra são detectados por sinais que a loja já emite. Nenhum evento manual, nenhuma mudança no checkout.
Quando o volume justifica, uma loja Tray recebe tratamento dedicado como o que já existe para outras plataformas: leitura direta da variante e adição pela API da loja. O ponto de partida é a mesma tag.
Preferimos dizer isso na página em vez de deixar você descobrir depois.
O catálogo é conector nativo e maduro: app instalado na loja, autorização renovada sozinha, produtos, variações, preços e imagens entrando e re-sincronizando em horário configurado. Essa metade funciona na Tray como funciona nas demais plataformas.
A loja usa o caminho genérico. O provador identifica o produto pelos dados estruturados que a página já publica e aciona o botão de compra do próprio tema. Funciona, é o mesmo caminho que atende lojas com plataforma própria, mas não é um módulo escrito para as particularidades da Tray, como existe para as plataformas que o índice marca no primeiro nível.
Na página de produto, o provador procura o código da peça nos dados estruturados que a loja publica para buscadores e comparadores, o mesmo padrão que o Google lê. Achando o código, confere se aquele item tem provador e injeta o botão.
Para adicionar ao carrinho, ele aciona o botão de compra da própria página. Quem adiciona é o tema, com o fluxo que ele já tem, então carrinho e sacola ficam consistentes.
O limite é conhecido: o resultado depende de a página publicar o código certo e de o botão responder ao acionamento. Em tema padrão isso costuma valer. Num tema muito customizado, é o que confirmamos antes de produção.
Dois pontos, e eles se verificam em minutos: se a página de produto publica os dados estruturados com o código da peça, e se o botão de comprar responde ao acionamento do provador.
Existe uma extensão de navegador que injeta o SDK em qualquer loja e mostra exatamente isso, o código resolvido e o fluxo de carrinho, sem a loja instalar nada. É assim que conferimos a sua antes de qualquer alteração no tema.
Sim. O catálogo entra por app instalado na loja, com OAuth, e na página de produto o provador identifica a peça pelos dados estruturados e aciona o botão de compra do tema.
Para o catálogo, sim: conector próprio com autorização renovada automaticamente. Na loja, o provador usa o caminho genérico, o mesmo que atende lojas com plataforma própria. O índice mostra quais plataformas têm módulo dedicado de loja.
Não. A autorização é renovada automaticamente antes de expirar, então a conexão não cai sozinha.
Dois pontos: que a página de produto publica os dados estruturados com o código da peça, e que o botão de comprar responde ao acionamento do provador. Confirmamos os dois com uma extensão de navegador, sem a loja instalar nada.
Não. É uma linha no <head> do tema, válida para todas as páginas. O botão de provar é injetado automaticamente na página de produto.
Não. A medição do funil usa sinais que a loja já emite, como URL, dados estruturados e cliques. Nenhum evento manual é necessário e o checkout não é alterado.