Olá — perguntou duas coisas na mesma mensagem: por que razão a sincronização dos seus três domínios disparou uma hora mais tarde do que definiu, e se deveria simplesmente mudar a sua equipa de otimização para autónomo já que está a mexer nisso. Acontece que são a mesma conversa, por isso vou tratá-las em conjunto em vez de dar duas respostas separadas.
Comece pela estrutura do sistema, porque isso explica os dois problemas. Todas as equipas aqui funcionam num de três modos — uma vez, manual, autónomo — e "autónomo" não é um nível separado e mais inteligente. É uma execução manual com um horário associado e o ciclo deixado em aberto. Mesmo agente, mesmas salvaguardas, tudo igual, apenas com um agendador a decidir quando clicar no botão em vez de si. Uma vez esclarecido isto, o resto encaixa.
Por que razão a sua sincronização e o seu horário estão em sítios diferentes
| Agendar | O que controla |
|---|---|
| Sincronização de dados | A recolha diária de dados do Search Console / Analytics / loja para os seus painéis — o combustível para tudo o resto |
| Execuções de agentes | Execuções de otimização automáticas após cada sincronização, varreduras de investigação a reabastecer a sua fila de briefings, e qualquer equipa que deixe em funcionamento |
Vai encontrar as definições de sincronização junto de cada domínio e as definições de execução junto de cada equipa — não numa única página combinada de automação, o que sei que parece estranho da primeira vez que se vai à procura. É, no entanto, deliberado. A sua cadência de sincronização é sobre os dados: com que rapidez o Search Console realmente atualiza. A sua cadência de execução é sobre a equipa: com que rapidez quer que essa equipa aja sobre o que vê. São perguntas diferentes com respostas diferentes, e uma versão anterior desta plataforma juntava as duas numa única página, o que fazia com que mexer numa arrastasse a outra consigo. Separá-las foi a solução.
Uma coisa que vale a pena saber antes de agendar seja o que for para a sua equipa de otimização: uma execução que dispara segundo um horário e uma execução iniciada manualmente produzem o mesmo objeto assim que arrancam. Mesmo relatório, mesma entrada no histórico, mesmo custo em créditos, mesma possibilidade de abri-la a meio e ver o que está a fazer. Já vi pessoas assumirem que as execuções agendadas são uma versão mais leve e reduzida para poupar custos — não são. Se não confiaria numa execução que iniciasse manualmente, não a coloque num temporizador.
O que realmente correu mal com o seu horário migrado
Mencionou ter colado a hora diretamente da sua ferramenta anterior — 14:00 UTC, com o objetivo de cair às 14h no seu horário. Essa é exatamente a armadilha. O nosso campo de hora quer o seu relógio local, não o UTC; mostra o fuso horário detetado mesmo por baixo, para nunca ter de adivinhar. Cole aí um valor UTC e ele é tratado como já sendo local, convertido para UTC uma segunda vez, e acaba com uma execução às 16h em vez das 14h. A correção para os seus outros dois domínios: volte a introduzir as horas em hora local, ignorando o valor UTC que a ferramenta anterior lhe deu.
A hora sobre a qual perguntou de facto — a sincronização a chegar às 7h em vez das 6h — é um efeito da hora de verão, e vale a pena perceber uma vez em vez de andar a perseguir todos os meses de março e outubro. Defina uma sincronização às 6:00 em Berlim em janeiro e a plataforma guarda 5:00 UTC, porque Berlim está em UTC+1 no inverno. Um agendador ingénuo continuaria simplesmente a disparar às 5:00 UTC para sempre. Com a mudança da hora de verão, Berlim passa a UTC+2, e essa mesma marcação das 5:00 UTC passa a corresponder às 7:00 locais — silenciosamente, sem erro, apenas números umas horas mais tarde do que esperava. Nós convertemos no momento de entrada em relação ao offset atual em vez disso, portanto um agendamento às 6:00 significa 6:00 no relógio local no dia em que corre, com ou sem hora de verão. Se continuar a ver um desvio de uma hora depois de reintroduzir a hora em local, vale a pena abrir um pedido de suporte — não deveria acontecer com um agendamento introduzido de novo.
Definir a cadência real
- Sincronização: diária, não mais rápida. Os dados do Search Console chegam com dois a três dias de atraso num bom dia. Sincronizar de hora a hora nos seus três domínios não lhe vai dar números mais recentes, apenas vai encher o histórico de sincronizações com tarefas que vão buscar repetidamente os mesmos dados atrasados.
- Otimização: encadeada com a sincronização, não com relógio próprio. Esta é a parte mais importante para o que está prestes a agendar. Se a sincronização terminar às 6:02 em vez das 6:00 porque a API da Google esteve lenta nessa manhã, a otimização é disparada logo a seguir, com esses dados recentes — não espera pela sua própria janela das 6:15 arriscando-se a correr sobre os números de ontem, caso a sincronização tenha demorado mais. Dois relógios independentes parecem bem até ao dia em que se desfasam.
- Investigação: semanal, dimensionada ao que a sua equipa de conteúdo consegue de facto processar. Os briefings não ficam desatualizados de um dia para o outro, e briefings por rever a acumularem-se numa fila continuam a custar créditos a produzir mesmo que ninguém aja sobre eles. Se a sua equipa conseguir realisticamente aprovar quatro ou cinco briefings por semana, dimensione a análise para produzir aproximadamente isso — uma análise diária a alimentar um hábito de revisão semanal apenas cria uma acumulação que ninguém chega a resolver.
- Anúncios, quando chegar a essa equipa no próximo mês: sem agendamento, de propósito. Os rascunhos são gerados a pedido; nada é publicado ou gasto sem a sua intervenção. O raciocínio está em o argumento contra o piloto automático de gastos, mas em resumo: um erro de agendamento numa sincronização de conteúdo é um incómodo menor, e um erro de agendamento em gastos publicitários é uma fatura. Não espere que as definições dessa equipa se pareçam com as que está a configurar hoje.
Então — deve mudar a otimização para autónoma?
Aqui está a resposta honesta, que é menos dramática do que a pergunta sugere: ativá-la muda menos do que se imagina. O agente não ganha nenhuma capacidade nova que não tivesse quando clicou em executar manualmente — os mesmos pontos de confirmação em qualquer ação destrutiva, os mesmos critérios, tudo igual. O que muda é apenas quem decide quando ele age. Neste momento, é você. Num agendamento, é o relógio.
A pergunta que eu de facto faria, em vez de "isto é seguro em modo autónomo", é esta: sente-se confortável com o resultado das suas últimas três execuções manuais de otimização a acontecerem outra vez, sem supervisão, na cadência que definir? Se sim, está pronto — ative-a. Se só se sente confortável porque reviu pessoalmente cada uma dessas três execuções antes de qualquer coisa avançar a partir delas, isso é um sinal real, e significa que continuar em modo manual mais um pouco é a decisão certa, não uma falta de coragem.
Dado o ponto em que está — três domínios acabados de migrar, horários ainda não totalmente estabilizados —, eu aguardaria mais alguns dias antes do modo autónomo. Corrija os dois agendamentos que faltam, observe a sincronização de amanhã a chegar à hora certa, execute a otimização manualmente mais duas ou três vezes para ver realmente o que ela faz do início ao fim. Depois agende-a. As questões de cadência acima ficam muito mais fáceis de responder com uma execução real à sua frente do que em abstrato, e não há custo nenhum em esperar uma semana para conseguir isso.
