Requisitos do conector de parceiro

Leia a Visão geral da publicação para entender as vantagens e o nível de compromisso necessário para publicar um conector. Para publicar um conector de parceiro, ele precisa atender a todos os requisitos descritos abaixo.

Apps Script

Antes de enviar seu conector para análise, conclua as seguintes etapas no Apps Script:

  1. Compartilhe o acesso de leitura do seu projeto do Apps Script com:
  2. Crie uma implantação chamada Production e atualize a implantação Production para a versão do código que você pretende publicar.
  3. Confirme se você atualizou a implantação Production para a versão do código que quer analisar.
  4. Confirme se o arquivo de manifesto está visível no Apps Script. À esquerda, clique em Configurações do projeto . Marque a caixa de seleção Mostrar arquivo de manifesto "appsscript.json" no editor.

Manifesto

Inclua os seguintes itens no manifesto do seu conector e confirme se o projeto do Apps Script está configurado para mostrar o arquivo de manifesto appsscript.json no editor.

Consulte a referência do manifesto do conector da comunidade para mais informações.

dataStudio

  1. description precisa fornecer informações e instruções para que você entenda os princípios básicos do conector e saiba como usá-lo. Conectores com descrições vagas e incompletas são rejeitados.
  2. addOnUrl é uma página hospedada dedicada sobre seu conector, de preferência hospedada no seu próprio domínio. A página precisa incluir o seguinte:
    • Uma Política de Privacidade e os Termos de Uso ou um link para esse conteúdo, no mesmo domínio do addOnUrl.
    • Detalhes que o usuário precisa saber para usar seu conector.
    • O link de inscrição, se for necessária uma conta para usar seu conector.
    • Conteúdo hospedado de preferência no seu domínio. A hospedagem em https://sites.google.com/ não é permitida.
    • Veja exemplos de páginas de parceiros existentes: Funnel, Supermetrics e CallRail.
  3. supportUrl precisa ser uma página hospedada para receber suporte para seu conector. Ele não pode ser um link de e-mail ou mailto.
  4. logoUrl precisa apontar para uma imagem estática hospedada sob seu controle. Não é possível usar imagens exibidas pelos Serviços do Google em domínios como *.gstatic.com, *.ggpht.com, *.google.com e *.googleusercontent.com. Usar o Google Cloud Storage para veicular imagens do domínio *.googleapis.com é aceitável e é uma opção de hospedagem recomendada.
    • Conectores com ícones animados serão rejeitados. Use imagens estáticas.
    • É recomendável usar pelo menos uma imagem de 48 x 48 pixels.
    • Evite imagens somente de texto que sejam difíceis de ler quando reduzidas para 48 x 48 pixels.
  5. Preencha a propriedade sources com todas as fontes conectadas ao conector. Consulte a referência Fontes no manifesto para mais detalhes.
    • Para ver a lista de fontes, consulte o repositório de registro de dados. Se você estiver se conectando a uma fonte que não existe no repositório, envie uma solicitação de envio ao repositório de registro de dados para incluí-la. Se as origens no seu manifesto não existirem no repositório, seu conector será reprovado no processo de análise.
    • Estes são metadados adicionais do conector que serão indexados para o recurso de pesquisa da galeria. Seu conector é exibido nos resultados da pesquisa quando os usuários procuram uma fonte específica na galeria.
  6. Forneça valores para shortDescription, authType, feeType, privacyPolicyUrl e termsOfServiceUrl.
  7. name precisa representar diretamente a finalidade do conector. Um nome claro ajuda os usuários a determinar se o conector atende às necessidades deles. Evite usar a palavra conector no nome, porque os usuários já sabem que estão vendo um conector.
    • Não inclua caracteres especiais ou não visíveis com a intenção de chamar atenção ou alterar potencialmente a posição do seu conector.
  8. Não use nomes abreviados para o Looker Studio em nenhum lugar do manifesto (por exemplo, GDS, DS etc.).
  9. Emojis não são permitidos em nenhum campo de manifesto (description, shortDescription, name etc.). Em geral, não inclua caracteres especiais ou não visíveis com a intenção de chamar a atenção para seu conector.
  10. Se ele tiver um esquema fixo, crie um modelo de relatório para ele e adicione-o ao manifesto. Ative a opção Compartilhamento por link para o relatório.

urlFetchWhitelist

  1. Limite os endpoints chamados pelo UrlFetchApp somente ao número necessário para que o conector funcione. Adicione a propriedade urlFetchWhitelist ao nível raiz do seu manifesto. Veja a referência de urlFetchChecklist para mais informações.
    • Inclua todos os endpoints usados com o serviço UrlFetchApp.
    • Se o conector não buscar recursos usando o serviço UrlFetchApp, defina urlFetchWhitelist como uma lista vazia [].
    • Se o conector não se conectar a um conjunto de endpoints fixos ou o prefixo do endpoint variar, omita a propriedade urlFetchWhitelist e forneça detalhes no campo Exceção para urlFetchAllowed ao enviar a solicitação de revisão.

oauthScopes

  1. Defina escopos OAuth explícitos no manifesto. Conectores sem escopos explícitos do OAuth serão rejeitados.

Conector

  1. Se o usuário precisar de uma conta para usar o conector, inclua instruções para a criação dela na description ou no link addOnUrl.
  2. Seu conector não pode estar incompleto ou em fase Beta. É necessário publicar um conector completo e funcional. Você sempre pode atualizar seu conector, mas a implantação de produção liberada para os usuários deve ser testada e o recurso precisa estar completo.
  3. Crie mensagens de erro claras e acionáveis para exibição aos usuários no caso de um erro interno do conector. Isso inclui os casos em que um usuário insere uma entrada inválida/em branco na configuração.
  4. Os links shortDescription, description, addOnUrl, supportUrl e a página OAuth (se aplicável) não podem ter erros ortográficos e gramaticais.
  5. shortDescription não pode conter URLs.
  6. Use métodos de autenticação fornecidos por getAuthType(). Não solicite credenciais via getConfig().
  7. Conclua o processo de verificação do cliente OAuth. Isso é obrigatório para todos os conectores, independentemente do método de autenticação em getAuthType(). O processo de verificação é diferente da análise de conectores e é realizado por uma equipe separada, não pelo Looker Studio. Consulte as perguntas frequentes sobre a verificação da API OAuth para mais informações. Seu conector será rejeitado se o processo de verificação do cliente OAuth não for concluído.
    • Durante o processo de verificação do OAuth, adicione os escopos do OAuth necessários do seu conector ao configurar a tela de consentimento. Se você não adicionar todos os escopos necessários, o processo de verificação do OAuth poderá ser aprovado, mas o conector ainda mostrará a tela App não verificado. Isso vai causar falhas no processo de verificação do conector de parceiro.
      Autorize e teste seu conector usando uma nova conta após concluir o processo de verificação do OAuth para garantir que a tela Aplicativo não verificado não seja exibida aos usuários.
  8. Verifique se você está em conformidade com os Termos de Serviço das galerias do Looker Studio (Remetente).

Quando você cumprir todos os requisitos, clique no botão a seguir para solicitar uma revisão do conector:

Publicar seu conector de parceiro