Hace unas semanas me llegó una invitación para participar en la beta del nuevo gestor de publicidad de Google, Google Ad Manager. La verdad es que había seguido de cerca el anuncio de este nuevo servicio y estaba convencido de que sustituiría a la aplicación que venía usando hasta ahora para gestionar las campañas de publicidad en nexoBlogs y OboLog.
Lamentablemente, después de haber estado una semana trasteando, configurando algunas campañas y haciendo pruebas reales en producción... lo que he hecho ha sido actualizar mi antiguo PhpAds al nuevo OpenX y aparcar la alternativa de Google. Google Ad Manager no ha cumplido con mis expectativas.
Estos son mis motivos:
- La prioridad de las campañas que comparten un "placement" o una zona determinada se basa exclusivamente en su rentabilidad, y esto no siempre es útil. Ejemplos: una misma zona en la que se muestran anuncios externos y anuncios in-house, de servicios propios. Ad Manager asigna una prioridad residual a las campañas in-house, al no generar éstas ningún beneficio económico. ¿No puedo asignar el mismo peso a una campaña propia, que a una externa de pago? Pues vamos bien.
- El banner que obtiene mejor CTR de una campaña, recibe automáticamente el 75% de las impresiones. Otra "automatización" incomprensible y que no puede desactivarse. ¿Y si se trata de una campaña de branding, en la que me interesa que todos los banners entren en rotación con los mismos pesos, independientemente del CTR que tenga cada uno? La respuesta de Google: recomiendan crear campañas ("line orders") diferentes para saltarse esta automatización. Raro, raro.
- Sólo disponen de un método de invocación para los banners: javascript. Pase con Google Adsense, por que Adsense sólo hay uno, y toca aguantarse, pero para un gestor de publicidad "abierto"... quiero poder escoger el sistema de invocación que yo quiera. Entre la librería propia de javascript, los scripts de medición de tráfico, los scripts de adsense, y el resto de llamadas varias (imágenes, css...) el tiempo de carga de la página se resiente. En el 99% de los casos, los iframes son la mejor solución para las creatividades llamadas desde un server externo: la carga se realiza de forma paralela e independiente a la de la página y no interfiere en el tiempo de carga total.
- Ademas: el código javascript que usan para la invocación es complicado y nada cómodo de implementar. La llamada de un banner se realiza siguiendo los siguientes pasos:
1. Llamada a la librería principal desde el header.
2. Función que verifica nuestra cuenta, también desde el header
3. De nuevo desde el header, deben especificarse todas las zonas que van a invocarse en la página actual.
4. Ya dentro de la página, se invoca la zona en cuestión con el identificador que corresponda.
Como veis, nada práctico si trabajáis con un sistema de templates que use headers y llamadas JS comunes. ¿Tengo que definir todas las posibles zonas por si las necesito en un momento dado? Pues vamos bien...
En fin, que no seré yo quien te diga que no lo pruebes... pero tenía que dejar constancia de mi decepción. La verdad es que al final algo bueno sí que he sacado de todo esto: la nueva versión de OpenX no está nada mal, es bastante más rápida que su predecesora y ha incorporado mejoras respecto a la generación de reportes e informes de rendimiento de las campañas.