Todo el que empieza a filtrar tráfico se topa con la misma elección: cloaker en la nube o un script de cloaking propio. Un cloaker en la nube es un servicio de cloaking que solo deja un pequeño código en tu sitio, mientras la decisión sobre cada visita se toma de su lado, con bases y verificaciones compartidas. Un script casero es tu propio código, normalmente en PHP, que mira la petición y decide por sí mismo a quién enviar a dónde.
Al principio la diferencia parece de dinero: el script es gratis y el servicio va por suscripción. En la práctica, la diferencia está en quién mantiene las bases de bots, quién responde por los errores y si se puede explicar por qué un clic concreto acabó donde no debía. Lo repasamos punto por punto, sin código de cloaker casero y sin publicidad.
Cloaker en la nube vs. script de cloaking: la diferencia
Ambos esquemas ocupan el mismo lugar: entre el clic del anuncio y la página que se muestra. Lo que cambia es dónde vive la lógica:
- Cloaker casero: las reglas y los datos están en tu servidor. El script mira la IP, el user-agent, el país según una base local y, quizá, una lista de direcciones que mantienes tú.
- Cloaker en la nube: en el sitio hay una etiqueta JS o un pequeño archivo PHP que envía los datos de la visita al servicio y recibe la respuesta «oferta» o «White Page». Las bases, la verificación del navegador, el registro de clics y los informes funcionan en el servicio.
Que sea «en la nube» no significa que el servicio se quede con tu sitio. Las páginas y el dominio siguen siendo tuyos; el servicio solo responde a la pregunta de qué mostrarle a quién. El principio se explica a fondo en el artículo cómo funciona un cloaker.
Cómo funciona un script PHP de cloaking casero
Si describimos un script de cloaking en PHP a nivel de idea, hace tres cosas:
- Lee los datos de la petición: dirección, cabeceras, idioma, referrer, parámetros del enlace.
- Los compara con sus reglas: país según una base local, lista de cadenas prohibidas en el user-agent, lista de direcciones.
- Devuelve una de dos páginas o hace una redirección.
Con eso basta para frenar las visitas más primitivas: escáneres que se delatan en el user-agent y visitas de países «ajenos». Pero un script así trabaja solo con lo que se ve en una petición. No comprueba si hay un navegador real delante, no ve el comportamiento en la página y no sabe que esa misma dirección se comportó como un bot en otro sitio hace una hora.
Comparativa: cloaker en la nube y script propio
| Criterio | Script casero | Cloaker en la nube |
|---|---|---|
| Bases de redes y bots | Las mantienes tú, a menudo desactualizadas | Las actualiza el servicio, comunes a todos los clientes |
| Verificación del navegador y del comportamiento | La escribes tú o no existe | Suele venir incluida |
| Actualizaciones | Trabajo tuyo, sin fin | Del lado del servicio |
| Carga | En tu hosting | Las verificaciones pesadas, en el servicio |
| Transparencia de decisiones | Solo si escribes tú el registro | Registro de clics con el motivo de cada decisión |
| Tracking y dinero | Tracker aparte y unión manual | A menudo tracker integrado |
| Dependencia | Solo de tu servidor | De la disponibilidad del servicio |
| Control sobre la lógica | Total | Dentro de los ajustes del servicio |
| Costo inicial | Tiempo de un desarrollador | Suscripción |
Ninguna columna «gana» en todas las filas. A continuación, cuáles de estas filas deciden de verdad.
Bases y señales: el punto débil del cloaker hecho en casa
Un cloaker hecho en casa casi siempre choca no con el código, sino con los datos. Para distinguir un bot de una persona hay que saber:
- qué redes pertenecen a hostings y nubes: son miles y cambian constantemente;
- qué direcciones son de VPN y proxies, incluidos los proxies residenciales, que parecen internet doméstico;
- qué direcciones ya fueron atrapadas automatizando;
- cómo se ven las versiones recientes de los navegadores automatizados.
Un script en un solo sitio solo ve su propio tráfico. Un servicio en la nube ve el tráfico de muchos clientes y reconoce al bot que llega a ti por primera vez pero que ayer ya cayó con otro cliente. No es magia, es efecto de escala, y no se puede replicar en un solo servidor. Qué señales se usan se explica en los artículos cómo filtrar bots y reputación de una dirección IP.
Actualizaciones y mantenimiento
Los bots cambian más rápido de lo que parece. Se actualiza el motor del navegador y cambian los rasgos de automatización. Un proveedor reparte nuevos rangos de direcciones y la base de redes queda vieja. La plataforma cambia el formato del identificador de clic y la regla que dependía de él empieza a fallar.
Con un script casero todo eso es trabajo tuyo, y normalmente te enteras de que hacía falta actualizar por una caída en las estadísticas o por la queja de «desaparecieron las conversiones». En un cloaker en la nube las actualizaciones son parte del servicio. Una aclaración honesta: si el servicio usa un archivo en tu servidor, ese archivo puede necesitar reemplazo cuando sale una versión nueva. Lo bueno es que el servicio diga claramente qué cambió y qué no sabe hacer tu versión actual.
Carga y velocidad
Un script simple es rápido: no consulta servicios externos y responde al instante. Pero en cuanto añades una verificación contra una base externa de direcciones, el registro de cada clic en una tabla y el conteo de visitas repetidas, la carga recae en tu hosting. Ante un pico de tráfico de una fuente push o pop, un hosting barato puede empezar a responder lento, y una landing lenta son conversiones perdidas.
El cloaker en la nube se queda con la parte pesada. El precio es una breve petición de red antes de mostrar la página. Suele ser una fracción de segundo, y hay que tenerlo en cuenta si tu fuente es especialmente sensible a la velocidad.
Transparencia de las decisiones
El punto más subestimado. La pregunta «¿por qué este clic fue a la White Page?» le surge a cualquier media buyer en la primera semana. Un script casero solo responderá si previste registrar el motivo de cada regla y una forma cómoda de consultarlo.
En un cloaker en la nube decente, el registro de clics con el motivo de la decisión es una función básica. En él se ve que una regla corta redes de servidores y no teléfonos normales, y se puede relajar una verificación concreta en lugar de ajustar todo a ciegas. Cómo leer esos motivos, en el artículo por qué el clic fue a la White Page.
Tracking y dinero
Un filtro sin tracking responde a «cuánto filtré», pero no a «si el tráfico es rentable». Para lo segundo hacen falta el identificador de clic, pasarlo a la red de afiliados, recibir postbacks, estados de conversión, gasto y ROI.
El script casero suele colocarse delante de un tracker aparte, y así aparece otro punto donde se puede perder el identificador de clic. En un cloaker en la nube el tracker suele venir integrado o hay una integración lista con los trackers populares. Cómo unir filtro y medición, en el artículo cloaker y tracker: la diferencia.
Cuándo tiene sentido un script de cloaking propio
Siendo honestos: hay casos, pero pocos.
- Para aprender. Entender cómo funciona el filtrado en un sitio de prueba propio.
- Un filtro geográfico mínimo. Solo necesitas bloquear países ajenos y los bots y el fraude no te preocupan.
- Un equipo de desarrollo propio. Hay alguien dispuesto a mantener siempre las bases, las verificaciones y la medición, y eso sale más barato que la suscripción.
En todos los demás casos, el tiempo de mantenimiento del script suele costar más que el servicio.
Riesgos de los scripts gratuitos ya hechos
Capítulo aparte es el «script de cloaking gratis» de chats y foros. Además de bases desactualizadas, ese código puede traer sorpresas desagradables: envío de tus enlaces y ofertas a un servidor ajeno, sustitución de tu enlace de afiliado por el de otro, vulnerabilidades por las que hackean el sitio. Si instalas código ajeno, léelo completo. Más sobre los riesgos de lo «gratis» en el artículo cloaker gratis.
Checklist: preguntas antes de elegir
Antes de escribir tu propio script o conectar un servicio, respóndete algunas preguntas:
- ¿Quién actualizará las bases de redes y direcciones de bots, y con qué frecuencia estás dispuesto a hacerlo?
- ¿Qué pasa ante una falla: la visita va a la White Page o la oferta se abre para todos?
- ¿Se puede ver el motivo de la decisión de cualquier clic una semana después?
- ¿Cómo llegará el identificador de clic a la red de afiliados y volverá por postback?
- ¿Aguantará el hosting un pico de tráfico si las verificaciones corren en él?
- ¿Quién más ve tus enlaces y ofertas: en el equipo, en el servicio, en el código que descargaste?
Si para las cuatro primeras preguntas la opción casera no tiene una respuesta segura, un cloaker en la nube casi seguro saldrá más barato. Un checklist detallado para elegir servicio está en cómo elegir un servicio de filtrado de tráfico, y qué averiguar antes de pagar, en comprar un cloaker: qué revisar.
Las políticas de las plataformas son iguales para ambas opciones
Elegir entre la nube y un script es una decisión técnica. Las políticas de las plataformas publicitarias no dependen de ella: mostrarle a la revisión algo distinto de lo que verá el usuario está prohibido, y por eso se suspenden cuentas junto con los perfiles vinculados. Ni el cloaker en la nube ni el script propio convierten una oferta prohibida en permitida.
La utilidad legítima del filtro es la misma en ambos casos: no pagar por bots ni clics fraudulentos, proteger tu campaña de los spy services y obtener estadísticas sin basura. La diferencia está solo en qué tan bien lo hace el filtro.
Cómo funciona el cloaker en la nube de ArtisanClo
ArtisanClo es un servicio en la nube de filtrado y enrutamiento de tráfico con tracker integrado. El esquema es este:
- Conexión: una etiqueta JS como primera línea en
<head>o un archivo PHP en tu hosting; para WordPress hay un plugin que instala ese mismo método PHP. Si el tráfico ya pasa por Keitaro o Binom, el filtro se integra en ellos. Detalles en el artículo cómo conectar un cloaker. - Una falla no abre la oferta. La etiqueta oculta la página hasta la decisión y envía a la White Page si no hay decisión; el filtro de Keitaro y la pasarela de Binom envían la visita a la White Page si el servicio no respondió en unos segundos.
- Las actualizaciones del archivo se ven. El archivo PHP del servidor no se actualiza solo, pero cuando sale una versión nueva aparece un aviso en la ventana de conexión con la lista de lo que tu versión no sabe hacer.
- Memoria compartida de bots. Una dirección atrapada con certeza como bot en un cliente recibe la White Page en su siguiente visita a cualquier flujo. A los visitantes reales con una red dudosa o con VPN no se les incluye ahí.
- Un motivo para cada clic. Decenas de motivos claros en el registro y un desglose de los rechazos por etapas: red y petición, verificación del navegador, verificación que no volvió.
- Tracker incluido. Clics, leads, ventas, gasto, beneficio y ROI, postbacks de redes de afiliados y envío de conversiones a las plataformas publicitarias.
Todas las funciones están en la página de funciones, y las condiciones, en la de precios. Hay un periodo de prueba gratuito que muestra el producto completo.
En resumen
- El cloaker en la nube decide del lado del servicio con bases compartidas; el script de cloaking decide en tu servidor con tus reglas.
- El punto débil del cloaker hecho en casa no es el código, sino los datos: las bases de redes, VPN y direcciones de bots hay que actualizarlas constantemente.
- La nube quita carga al hosting y da un registro con los motivos de cada decisión, pero añade dependencia de la disponibilidad del servicio: comprueba que, ante una falla, la visita vaya a la White Page.
- Un script propio tiene sentido para aprender, para un filtro geográfico simple o si cuentas con tu propio equipo de desarrollo.
- Las políticas de las plataformas son iguales para ambas opciones: el filtro sirve contra bots, fraude y copias, no para eludir la revisión.
