Dolphin{anty} para publishers: como organizar uma operação com dezenas de sites

Administrar um site costuma ser relativamente simples. O editor acessa o WordPress, acompanha o Google Analytics e o Search Console, utiliza suas ferramentas de SEO, publica nas redes sociais e segue a rotina.

O cenário muda quando a mesma empresa passa a administrar 10, 20 ou 50 sites.

Uma publisher pode ter vários editores, profissionais de SEO, social media, gestores e responsáveis por diferentes marcas trabalhando simultaneamente. Cada projeto traz seu próprio CMS, contas de Analytics, Search Console, redes sociais, ferramentas, logins e permissões.

Nesse estágio, o desafio deixa de ser apenas produzir e publicar conteúdo. Também passa a ser necessário organizar os ambientes em que todo esse trabalho acontece.

É nesse contexto que o navegador pode deixar de ser apenas uma ferramenta de acesso e começar a fazer parte da infraestrutura operacional de uma equipe editorial.

Gerenciar vários sites aumenta a complexidade da operação

Quando existe apenas um projeto, manter algumas contas conectadas no navegador normalmente não representa um problema.

Em uma rede com dezenas de sites, porém, a equipe passa o dia alternando entre diferentes contextos. Um editor pode terminar uma alteração em um portal e, minutos depois, começar a trabalhar em outro. O profissional de SEO consulta diferentes propriedades do Search Console e do Analytics. O social media precisa acessar várias contas de marcas distintas.

Nesse processo, sessões permanecem abertas, extensões continuam ativas, abas se acumulam e diferentes usuários podem estar conectados ao mesmo navegador.

O problema não está necessariamente em um erro isolado. Está na repetição dessas pequenas trocas de contexto ao longo do dia.

Com o crescimento da operação, perguntas simples começam a consumir tempo: qual conta está conectada? Este Analytics pertence a qual projeto? Qual usuário deve ser utilizado? Quais ferramentas fazem parte daquele site? Quem trabalhou nesse ambiente anteriormente?

As informações normalmente existem, mas podem estar espalhadas entre gerenciadores de senhas, documentos internos, ferramentas de gestão de projetos, mensagens e o conhecimento dos próprios membros da equipe.

Quanto maior a publisher, maior tende a ser esse volume de contexto.

O problema pode estar em misturar projetos no mesmo ambiente

Administrar muitos sites não significa necessariamente que todos eles precisem compartilhar o mesmo ambiente de trabalho.

Uma alternativa é separar os projetos também no navegador.

O Site A pode ter um ambiente próprio, enquanto o Site B utiliza outro. Cada um preserva seu contexto de trabalho e os acessos relacionados àquele projeto.

Assim, quando um profissional começa a trabalhar em determinado site, não precisa primeiro identificar quais contas deveriam estar conectadas ou quais ferramentas pertencem àquela operação.

Essa separação também reduz a quantidade de decisões pequenas que precisam ser tomadas a cada mudança de projeto.

Em vez de adaptar constantemente um único navegador para trabalhos diferentes, a equipe passa a entrar diretamente no contexto correspondente ao site que precisa administrar.

Separar o navegador pessoal do profissional já segue essa lógica

A ideia não é tão diferente de algo que muitos profissionais já fazem.

É comum manter o navegador usado para trabalho separado daquele utilizado para e-mail pessoal, redes sociais, compras e outras atividades particulares. Isso evita misturar históricos, contas, sessões, favoritos e extensões de contextos diferentes.

Em uma publisher, o mesmo raciocínio pode ser levado um pouco adiante.

Se faz sentido separar o ambiente pessoal do profissional, uma operação com dezenas de sites também pode se beneficiar da separação entre os próprios projetos profissionais.

Cada site passa a ter seu contexto, suas contas e suas ferramentas, enquanto a equipe acessa apenas os ambientes necessários para executar o trabalho.

Como o Dolphin{anty} pode ser usado por publishers

É nesse ponto que o Dolphin{anty}↗ pode assumir uma função diferente daquela normalmente associada a navegadores antidetect.

Dentro da ferramenta, uma publisher pode criar um perfil separado para cada site, marca ou projeto editorial.

Em vez de utilizar o mesmo ambiente para acessar diferentes WordPress, propriedades do Analytics, Search Console, redes sociais e plataformas de trabalho, cada projeto pode permanecer dentro do seu próprio perfil.

Os perfis podem ser agrupados em pastas e organizados com tags e status. Em operações que utilizam os recursos de colaboração do Dolphin{anty}↗, também é possível distribuir o acesso aos ambientes de acordo com as responsabilidades da equipe.

Isso não significa que WordPress, Google Analytics, Search Console ou ferramentas de SEO tenham integração nativa com o Dolphin{anty}↗.

A função aqui é outra: organizar o ambiente de navegador usado para acessar esses serviços.

O Dolphin{anty} não substitui um CMS, um gerenciador de senhas ou uma plataforma de gestão de projetos. Ele atua em outra parte da estrutura, mantendo diferentes contextos de navegação separados.

Como organizar uma publisher com 15 sites

Imagine uma empresa que administra três verticais editoriais: tecnologia, games e finanças.

Cada vertical possui cinco sites.

Em vez de todos esses projetos serem administrados dentro dos mesmos ambientes de navegador, a empresa poderia criar uma estrutura em que cada vertical possui sua própria pasta e cada site possui um perfil separado.

Assim, os cinco projetos de tecnologia permanecem agrupados, os cinco sites de games formam outro conjunto e os projetos financeiros ficam em uma terceira estrutura.

Cada perfil corresponde ao ambiente de um site específico.

Tags e status podem ajudar a classificar os projetos, enquanto a distribuição de acesso acompanha as responsabilidades de cada profissional.

Um editor dedicado aos projetos de games, por exemplo, não precisa trabalhar constantemente em meio aos ambientes da vertical financeira. Da mesma forma, alguém responsável por apenas três sites pode receber acesso somente aos projetos necessários para sua função.

A intenção não é acrescentar complexidade.

É organizar uma complexidade que já existe.

Se a empresa possui 15 sites, dezenas de contas, várias ferramentas e diferentes profissionais, toda essa estrutura já precisa ser administrada de alguma maneira. A separação dos ambientes apenas torna essa divisão mais explícita.

A organização também facilita o trabalho em equipe

O ganho não está apenas em separar contas.

Uma operação editorial normalmente possui diferentes responsabilidades. Editores trabalham principalmente com CMS e publicação. Profissionais de SEO utilizam Analytics, Search Console e ferramentas de pesquisa. Social media administra contas sociais, enquanto gestores precisam acompanhar vários projetos.

Nem todos precisam necessariamente utilizar os mesmos ambientes.

Organizar os projetos dessa maneira ajuda a responder questões importantes para a operação: quem trabalha em determinado site, quais ferramentas fazem parte daquele projeto e quem precisa ter acesso ao ambiente.

Isso também pode facilitar transições dentro da equipe.

Quando uma nova pessoa entra em um projeto, encontrar o contexto necessário para começar a trabalhar se torna mais simples. Quando alguém deixa a operação, também fica mais fácil identificar os ambientes relacionados às suas responsabilidades.

O navegador deixa de ser apenas um espaço individual e começa a refletir a própria estrutura da empresa.

Quando esse tipo de estrutura começa a fazer sentido?

Não existe um número exato de sites a partir do qual uma publisher precisa separar seus ambientes.

Uma pessoa que administra um único blog provavelmente não precisa criar uma estrutura complexa para isso. Mesmo uma pequena rede de sites pode funcionar perfeitamente com ferramentas convencionais, dependendo da equipe e do fluxo de trabalho.

A necessidade cresce junto com a operação.

Quanto maior o número de sites, contas, marcas, profissionais e ferramentas utilizados diariamente, maior tende a ser o custo das constantes mudanças de contexto.

É nesse cenário que o Dolphin{anty}↗ pode ganhar uma aplicação menos óbvia para publishers: funcionar como uma camada de organização entre os projetos e os ambientes utilizados pela equipe para trabalhar neles.

Quando uma empresa administra um site, o navegador pode ser apenas uma ferramenta.

Quando uma equipe administra dezenas deles, ele começa a fazer parte da infraestrutura.

Perguntas frequentes O Dolphin{anty}↗ pode ser usado para administrar vários sites?

Sim. Uma possível aplicação é criar ambientes separados para diferentes sites ou projetos, mantendo suas respectivas sessões e contextos de navegação organizados. Isso não substitui o CMS nem as ferramentas utilizadas pela publisher.

É necessário usar um navegador antidetect para administrar um blog?

Não. Para um único site ou uma operação pequena, essa estrutura pode ser desnecessária. A utilidade tende a aumentar quando vários projetos, contas e profissionais precisam ser organizados simultaneamente.

O Dolphin{anty} integra WordPress, Analytics ou Search Console?

Não é essa a proposta. Esses serviços continuam sendo acessados normalmente. O Dolphin{anty} funciona como o ambiente de navegador onde a equipe pode manter diferentes projetos separados.