¿Convierte la web de Milanuncios?


El pasado jueves desayunábamos con la noticia de la venta de Milanuncios al grupo Schibsted Classified Media (SCM), dueño de los portales Fotocasa, Infojobs y SegundaMano. Es, sin duda, una de las mayores operaciones de compra-venta en el sector de Internet en España. En los pocos días que han transcurrido desde la noticias ya se ha escrito mucho en todos los medios digitales al respecto y yo no voy a aportar nada nuevo.

No obstante, quiero aprovechar para desarrollar un poco una breve conversación que tuve con Juan Macías en Twitter, iniciada por Aquilino Peña, al respecto de la conversión y el UX de Milanuncios.

Aquí os dejo la conversación completa.

Antes de nada os dejo un enlace al post que ha publicado Juan sobre Milanuncios, un ejemplo de cómo se debe argumentar una opinión. Ese es el camino que en este post defiendo a la hora de hablar sobre cosas tan objetivas como la conversión de una web.

Mi opinión es que, a pesar de las opiniones de muchos expertos, el UX de Milanuncios no es tan malo como quieren pensar. Lo importante cuando se habla de conversión son los números y en eso Milanuncios es impresionante. Estoy de acuerdo en que todo es mejorable y que no hay que quedarse sólo en el “si funciona, no lo toques”. Cuando hablamos de conversión y optimización de una web, hay que estar siempre buscando la excelencia, haciendo constantes cambios, midiendo y viendo si se ha mejorado o se ha vuelto atrás.

Pero en el caso de Milanuncios, mi TL se ha llenado de gente diciendo que la web era malísima y que no convertía. Lo decían sin datos y, sobre todo, sin haber hecho un estudio real y serio con usuarios para ver dónde falla y ver dónde y cómo se puede mejorar. Lo decían basándose en su opinión y experiencia de lo que supuestamente funciona pero sin conocer los datos de conversión de Milanuncios. Es la típica historia española: alguien tiene una historia de éxito y, en lugar de aprender al máximo de ella, buscamos sacar los puntos supuestamente malos para criticar.

Yo no soy experto en UX. Es más, apenas se nada de UX. Lo único que se es lo que los datos me demuestran y que, prácticamente simpre, me enseñan que mi primera opinión es erronea. Por ello, no voy a decir si Milanuncios convierte bien o mal, si el diseño es bueno o malo, etc… Sólo quiero decir que antes de emitir juicios de ese estilo, seamos serios y hagámoslo en base a datos reales y no sólo a opinones personales que, como todo lo subjetivo, tiene poco o nulo respaldo en datos reales.

¿Se basará el modelo de negocio de Milanuncios en la no conversión?

El health check del ELB de AWS y el contenido duplicado en Google


Como ya había comentado anteriormente, la infraestructura de etece está en la nube de Amazon. Uno de los servicios que tenemos contratados es el de balanceador de carga (ELB) para distribuir el tráfico entre diferentes frontales y así poder autoescalar cuando tenemos picos de tráfico.

Como parte de la configuración del ELB se debe definir el health check. Esto es, una petición que realiza el balanceador a cada una de las máquinas virtuales (EC2) que tiene detrás para determinar si la máquina está funcionando bien o por el contrario tiene algún problema y debe sacarla del balanceo. Este health check se configura mediante:
– protocolo
– puerto
– path de la petición
– timeout de la respuesta
– intervalo entre peticiones
– umbral no sano. Indica el número de veces seguidas en que tolera una respueta incorrecta y a partir de la cuál saca la máquina del balanceador
– umbral sano. Indica el número de veces seguidas en que recibe una respuesta correcta que espera antes de volver a meter una máquina en el balanceador

En el caso de etece tenemos configurado que pida una página cada seis segundos, con un umbral no sano de 2 y un umbral sano de 4. Esto significa que si una máquina no responde adecuadamente durante doce segundos (umbral inferior de 2 con una petición cada 6 segundos), el ELB saca dicha máquina del balanceo. Cuando esa máquina responde correctamente durante 24 segundos (umbral superior de 4 con una petición cada 6 segundos), el ELB la vuelve a incluir en el balanceo.

La petición configurada la hace el ELB a cada una de las EC2 haciendo uso de su DNS público. Esto es un nombre público que tiene cada EC2 durante su tiempo de vida. Si paras la máquina y la vuelves a levantar, cambia su DNS público por lo que no puedes ni debes hacer ninguna configuración mediante ese nombre ya que va a cambiar. Además, si tus frontales autoescalan, todos ellos serán iguales, con la misma configuración pero con diferente DNS público.
Es decir, si yo tengo un EC2 sirviendo peticiones para el dominio midominio.com y ese EC2 tiene un DNS público que es ec2-xx-xx-xx-xx.eu-west-x.compute.amazonaws.com, el ELB va a hacer la petición http configurada en el parámetro path de la petición (por ejemplo /index.html) a este nombre público. Va a pedir http://ec2-xx-xx-xx-xx.eu-west-x.compute.amazonaws.com/index.html. Lo que comprueba el health check es el código de respuesta, dándo únicamente por válida una respuesta 200. Cualquier otra respuesta es considerada respuesta erronea. Por tanto, no puede haber ninguna redirección en esa respuesta.

Hasta aquí no he contado nada nuevo y seguro que muchos ya estáis pensando que soy un poco pesado. Pero cuando empiezas a tirar de la cuerda es cuando ves que hay más tela que cortar y que hay que hilar fino.

Configuración del virtual host de Apache
Si quieres que tu web responda correctamente al health check del ELB evitando las redirecciones, debes tener configurados los virtual host de Apache para que respondan por midominio.com y para el DNS público, que es un valor dinámico. Se podría resolver muy facilmente haciendo que el virtual host de midominio.com sea el virtual host por defecto y todo resuelto. Si pero no. Aquí es donde entra nuestro colega Google.

Si alguna vez, por comprobar el funcionamiento de tu EC2 o porque tienes el EC2 fuera del ELB, haces una petición de tu web por el DNS público, se van a imprimir todos los pixels de analítica, remarketing, conversión etc… que tengas en tu web, pero con un nombre de servidor que no es el de dominio. Google es muy listo y se guarda esa info en algún lugar para luego volver a ella y lo normal es que te indexe varias páginas iguales respondiendo por midominio.com y el DNS público. Total, mismo contenido con dos URLs y eso es penalización segura. Hay que corregirlo en cuanto te das cuenta. En el caso de etece, no somos tan listos como para habernos dado cuenta nosotros solos. Ha sido nuestra amiga Noe la que nos ha avisado del percal. Gracias Noe!!!!

Solución
Después de darle varias vueltas a las diferentes alternativas, hemos decidido que la que más nos gustaba era configurar el virtual host de midominio.com para que redirija todas las peticiones que gestione a midominio.com excepto cuando el user-agent de la petición es el que usa ELB para hacer las peticiones de health check (ELB-HealthChecker/1.0). En ese caso responde por el DNS público y en cualquier otro caso, hace una 301 a midominio.com. De esta manera evitamos que se respondan peticiones por dos URLs distintas y el ELB puede hacer el health check correctamente. Para ello hemos recurrido a la directiva RedirectRule en base a algunas condiciones expecificadas en la directiva RewriteCond, ambas del mod_rewrite de Apache.

Nuestra configuración ha quedado así:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} !ELB-HealthChecker
RewriteCond %{SERVER_NAME} !midominio.com
RewriteRule /(.*) http://midominio.com/$1 [L,R=301]

 

— ACTUALIZACIÓN 11-07-2013

Si usas CloudFront como CDN usando subdominios de tu dominio, que son servidos por el mismo server, la configuración que había publicado no funciona correctamente ya que, al no ser una petición con el SERVER_NAME midominio.com, al venir desde CloudFront, la regla le hace una 301 a midominio.com y por tanto estaría sirviendo todo el contenido estático nuestro servidor, perdiendo las virtudes del CDN. Por tanto, hay que incluir una nueva condición para evitar la redirección si quien lo pide es CloudFront.

Nuestra nueva configuración ha quedado así:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} !ELB-HealthChecker
RewriteCond %{HTTP_USER_AGENT} !Amazon\ CloudFront
RewriteCond %{HTTP_HOST} !midominio.com
RewriteRule /(.*) http://midominio.com/$1 [L,R=301]

Para el que no esté muy suelto con las directivas de Apache, esto lo que significa es:

Activamos el motor de reescritura
Si el user-agent de la petición NO es ELB-HealthChecker/1.0 Y….  –> Si es ELB-HealthChecker/1.0 entonces no se hace nada
Si el user-agent de la petición NO es CloudFront Y….  –> Si quien hace la petición es CloudFront entonces no se hace nada
Si el nombre de dominio pedido NO es midominio.com entonces…  –> Si el nombre de dominio ya es midominio.com no se hace nada, de esta manera se evitan los bucles de redirecciones
Se hace una 301 a midominio.com

Espero que este breve artículo le sirva a más de uno para evitar un problema de duplicidad de URLs. Es cierto que lo podía haber explicado de manera más breve pero creo que así se entiende mejor. Como siempre, cualquier comentario o corrección es bienvenida.

Qué enseñar hoy a los niños ante un futuro profesional tan complicado


Esta noche estaba cenando en casa, con mi hijo de dos años y poco sentado a mi lado y con la cabeza llena de reflexiones varias. Me apetecía escribir un post para mi blog pero no tenía claro sobre qué escribir. Entonces puse un tweet pidiendo ideas y Rosa Poo, fundadora de emprendekids.com, me contestó sugiriéndome el título de este post. En ese momento me puse a darle vueltas a este tema intentado ordenar todas las ideas y, sobre todo, a pensar en qué me gustaría transmitir a mi hijo y a su generación en relación a este tema.

Cómo veo el futuro profesional
El entorno laboral está en continuo cambio. A temporadas el cambio es lento y otras veces es vertiginoso. Cómo era cuando nuestros padres eran jóvenes es muy diferente a cómo es ahora y a su vez es muy distinto a cómo será cuando mi hijo esté en edad de trabajar. Ya no habrá trabajos que duren toda una vida. El marco legal se habrá adaptado a contrataciones y despidos rápidos y baratos, no habrá cotizaciones para las pensiones porque no habrá. Los buenos profesionales y aquellos que tengan el mayor talento dominarán el mercado y serán el modelo a seguir. En resumen, será un entorno bastante hostil y complicado.

No todo ha cambiado y algo no cambiará
La vida me ha enseñado que las cosas te pueden salir bien o mal, puedes tener más o menos talento o facilidad para determinadas cosas e incluso puedes tener la suerte a favor o en contra pero el esfuerzo siempre tiene su recompensa. He visto a gente que ha suplido su mala suerte, falta de talento o pérdida de capacidad con esfuerzo y además se trata de una circunstancia prácticamente invariable con el tiempo.

Sin saber cómo va a ser la vida que va a vivir mi hijo, si tuviera que enseñarle una sola cosa que le fuera a valer profesionalmente en su vida sería a esforzarse. Esfuerzo constante y sincero. El esfuerzo sincero parte de la base de conocerse a uno mismo, saber hasta dónde se puede llegar con el mínimo esfuerzo y a trabajar diariamente para ir más allá de esa barrera del mínimo esfuerzo para conseguir los objetivos marcados. Ese esfuerzo, con el tiempo y el trabajo, se convierte en rutina y entonces es cuando se llega a un punto en el que se puede afrontar cualquier reto con garantías. Además, afrontar las cosas con este esfuerzo constante y sincero hace que se vivan los fracasos de otra manera, sabiendo que se ha hecho todo lo posible y asumiendo las limitaciones reales de uno mismo, pudiendo construir a partir de ahí.

Eso es muy fácil de decir pero muy difícil de hacer. No soy educador, tengo poca experiencia docente y soy padre primerizo por lo que, casi seguro, soy el menos indicado para decir cómo se debe inculcar la cultura del esfuerzo a los niños. No obstante me gustaría aportar mi granito de arena en la formación de una nueva generación que tenga entre uno de sus pilares el esfuerzo.

Hoy me he puesto bastante más reflexivo y profundo de lo que acostumbro, pero prometo volver a mis post de carácter más técnico en breve.

SQA en una startup


SQA (software quality assurance) o aseguramiento (vaya palabro) de la calidad del software es un concepto con el que convivimos los que nos dedicamos, de una u otra manera, al desarrollo de software. Definir qué es el SQA es algo complicado y cada uno tendrá una versión distinta pero para mi no es más que la colección de procesos y herramientas que permite asegurar en cada nueva release que el software desarrollado tiene la calidad suficiente como para poder ser desplegado en producción. Existen metodologías muy desarrolladas en torno a este tema pero yo prefiero ir a lo práctico y sencillo y al final lo reduzco a una serie de pruebas funcionales que debe pasar el software. Estas pruebas deben cubrir todos los procesos de negocio soportados por el software, tanto el funcionamiento esperado como los errores controlados.

La gestión de la calidad del software debería formar parte de manera natural del ciclo de vida del software pero todos sabemos que no es así. En casi todos los proyectos brilla por su ausencia.

SQA en una startup

En la mayoría de los casos, unir en una misma frase startup y SQA es ciencia ficción. Casi siempre en las startups tendemos a confundir rapidez, agilidad y calidad. Pero claro, los recursos y el tiempo en una startup son muy limitados y si hay que reducir por algún sitio, normalmente suele ser a costa de suprimir el SQA. Aunque por otro lado, nuestra tolerancia a los errores es muy baja y siempre queremos que las cosas funcionen perfectamente. Estoy seguro que a muchos os ha venido a la cabeza alguna conversación con vuestro CEO en la que habéis discutido sobre la necesidad de hacer un desarrollo para ayer pero luego, cuando las cosas han fallado por hacerlas deprisa y corriendo, ha puesto el grito en el cielo.

Cuando nos movemos en el entorno de una startup, parece bastante asumido que el SQA hay que dejarlo para más adelante, para cuando la empresa deja de ser una startup y te puedes parar un poco a afianzar todo. Algunos ejemplos:

  • En BuyVIP durante el tiempo que  fui CTO no teníamos ni un plan de pruebas definido ni un proceso de pruebas exaustivo previo al paso a producción.
  • En tagUin, teníamos una guía básica de qué había que comprobar y teníamos en la cabeza el detalle de lo que había que probar pero no lo hacíamos siempre y casi siempre nos dejábamos cosas por probar.
  • En Planeo mientras yo gestioné el proyecto, nunca hubo plan de pruebas y la parte de negocio nunca se involucró lo suficiente en hacer pruebas funcionales de calidad. Así pasaba, que casi siempre había errores totalmente evitables si el negocio hubiera probado lo que le pedíamos que probara.

Qué hacíamos en etece

Digo “hacíamos” y no hacemos porque estamos trabajando para cambiar y mejorar el SQA. Un poco más adelante os cuento qué estamos haciendo.

Desde la primera versión de etece que vio la luz a mediados de julio de 2012, hemos tenido un documento muy sencillo donde hemos ido incorporando las pruebas que considerámos necesarias para comprobar, en cada nueva release, que todo funciona según esperamos. En esa primera versión eran alrededor de unas 80 pruebas. Ahora vamos por casi 300. Estas son algunas de nuestras pruebas:

  • Grupo: registro de cliente
  • Prueba: registro correcto de cliente
  • Pre-requisitos: ninguno
  • Descripción: desde la home, se accede al registro de cliente, se completan todos los datos con un email que no haya sido registrado previamente y se completa el registro
  • Resultado esperado: 1.- Llega correctamente el email de bienvenida; 2.- El usuario está correctamente registrado en el CRM; 3.- El cliente queda correctamente suscrito a las listas usuarios y clientes tanto en la web como en MailChimp
  • Grupo: registro de cliente
  • Prueba: registro de cliente con email dado de baja
  • Pre-requisitos: disponer de un usuario registrado y dado de baja
  • Descripción: desde la home, se accede al registro de cliente, se completan todos los datos usando el email de un usuario dado de baja y se intenta completar el registro
  • Resultado esperado: El registro no se completa, se muestra un mensaje genérico de error y además se marca en rojo el campo email indicando que ya existe

Al principio, hacer todas las pruebas nos llevaba un día de una persona. Ahora, con casi 300 estamos en un par de días de dos personas. Además, según vamos incorporando funcionalidad a la web, las pruebas cada vez son más complejas y requiren de más tiempo. Estaba claro que teníamos que ir un paso más allá, automatizando las pruebas.

Qué estamos haciendo ahora en etece

Desde hace un par de semanas estamos trabajando para automatizar el mayor número de pruebas que podamos. Las ventajas de automatizar las pruebas son claras:

  1. mejora del tiempo necesario para pasar el plan de pruebas.
  2. minimizar la intervención humana. No hace falta, en un procentaje grande, que intervenga ninguna persona.
  3. mejorara la calidad de las pruebas. Es casi consecuencia del punto anterior. Al eliminar el factor humano, eliminamos aquellas pruebas que se dan por buenas por error o que directamente, la persona encargada no las hace ( pasa más de lo que pensáis).
  4. hay que ser más metodológico. Todo lo nuevo que se desarrolla o que se modifica debe tener sus pruebas funcionales programadas. Es algo bueno, pero también lo incluyo como punto negativo ya que muchas veces te puede complicar de más algún desarrollo.

En cambio, hay que asumir algunos puntos negativos:

  1. aumento del tiempo de desarrollo. Ahora, además de programar la funcionalidad, hay que programar las pruebas que comprueban que todo funciona correctamente y hay que mantener operativas las pruebas ya programadas. Estimamos que el tiempo se va a aumentar entre un 10% y un 15%.
  2. hay que se más metodológico.

Para automatizar las pruebas  estamos usando Seleniun2 con JUnit4. En los próximos días publicaré un post escrito por Javier Fernandez que explica a nivel técnico cómo está montada toda la automatizacion de pruebas. Avanzando un poco de lo que él contará, para cada una de las pruebas que teníamos escritas es nuestro plan de pruebas, hemos creado un test de Selenium que hace el proceso completo de la prueba y comprueba todos los resultados esperados. Hemos hecho cada prueba independiente de la anterior de manera que una prueba empieza sin necesitar datos anteriores, se ejecuta y al terminar borra todo rastro para así poder ser ejecutada de nuevo sin problemas. Como imaginaréis, hay muchos procesos que están compartidos entre muchas pruebas (registro de usuario, registro de solucionador, encargar una tarea, etc…) por lo que la estructura de clases que hemos montado nos permite independizar del test toda esta navegación común. El plan de pruebas lo lanzamos desde nuestro servidor de integración contínua (Jenkins) lo que nos permite conocer en todo momento la salud de nuestro proyecto.

Hasta la fecha hemos conseguido automatizar alrededor de un 90% de las pruebas del plan lo que reduce a poco más de un par de horas el trabajo el tiempo humano necesario para completar las pruebas.

Espero que estas líneas os sirvan de estímulo para incluir, de manera más o menos sencilla, el SQA como parte de vuestros proyecto.

Personas, procesos, herramientas


A lo largo de mi carrera siempre he intentado aprender lo máximo de la gente que tengo alrededor. He intentado quedarme con lo mejor de cada uno de los profesionales con los que he trabajado y trabajo, sobre todo de aquellos que han tenido más experiencia o conocimientos que yo.
De Gustavo García, cofundador de BuyVIP, aprendí que una empresa se sustenta en tres patas: personas, procesos y herramientas.

Para que una empresa funcione, las personas de los puestos clave deben ser muy solventes, con mucho talento y capaces de definir e implementar los procesos sobre los que soportar, de una manera eficiente, las necesidades del negocio. Las herramientas deben permitir ejecutar los procesos de manera rápida y sencilla con la menor cantidad posible de personal.

Según se desarrolla una empresa, cada una de las tres patas debe crecer de manera similar de forma que no haya grandes desfases entre ellas. Una empresa con muchas personas pero sin procesos y/o herramientas no es eficiente. Igualmente, una empresa sin el talento suficiente no tendrá los procesos definidos de manera eficiente y no se hará un uso adecuado de las herramientas. Una empresa sin herramientas necesitará mucho personal, agudizando el desfase entre las tres patas.

Cómo aplicamos esto en una startup
Cuando una empresa arranca, no tiene personas, procesos o herramientas. Por tanto, por algún punto hay que empezar. El punto de partida es, como no podía ser de otra manera, las personas. Yo creo firmemente que, al menos, las diez primeras personas de una startup deben ser sobresalientes, con un talento enorme, autonomía y liderazgo. Esas diez personas (aproximadamente) deben ser capaces de definir, desarrollar e implantar, en cada una de las áreas, los procesos y las herramientas. ¿Tienes en tu empresa las personas adecuadas sobre las que sustentar el crecimiento? Merece la pena invertir el tiempo necesario para buscar y seleccionar esas personas. En gran medida, el éxito de tu empresas dependerá de ello.

Impacto de salir en TV sobre la infraestructura de etece


El pasado 13 de febrero de 2013 TVE emitió el programa Comando Actualidad hablando sobre consumo colaborativo. Una pequeña parte del programa mostró el funcionamiento de etece a través del día a día de nuestro trabajo y el de algunos solucionadores.
Con independencia del impacto en el negocio, quiero compartir el impacto que tuvo en nuestra infraestructura, cómo planificamos la escalabilidad y qué hicimos bien y mal, esperando que sea útil para otras empresas que vayan a pasar por situaciones similares.

Cómo está montada nuestra infraestructura
Tal y como comentaba en un post anterior, nuestra infraestructura está en la nube de Amazón. Una de las características que ofrece es la capacidad de auto escalado en función de la carga que están soportando las máquinas virtuales EC2. Para poderte beneficiar de esta característica, la arquitectura debe estar concebida para ello. No voy a entrar en detalle sobre cómo montar grupos de auto escalado porque ya hay mucha literatura al respecto y no es el propósito de este post. No obstante, si alguien quiere que lo detalle, lo haré sin problema.
Nuestro grupo de auto escalado está configurado para tener como mínimo una máquina, ya que normalmente tenemos poco tráfico, añadiendo una máquina cada vez que la CPU de las máquinas que forman el grupo supera el 75% de carga. Este chequeo de la carga de la CPU del grupo se hace cada minuto (no se puede configurar cada menos). Eso quiere decir que, ante un pico de carga, escalamos añadiendo una máquina por minuto. Teniendo en cuenta que en levantar una nueva máquina lleva entre 20 y 30 segundos, desde que se supera el umbral de carga, tardamos 30 segundos como mínimo y 90 como máximo en incrementar el número de máquinas.

Cómo nos preparamos para el presumible pico de tráfico
Presuponiendo que salir en TV nos iba a suponer un pico de tráfico, modificamos el grupo para que tuviera como mínimo 10 máquinas. En Amazón se paga por tiempo de uso de las máquinas (además de tráfico y alguna cosa más) por lo que tener muchas máquinas durante un rato sólo supone un sobrecoste de unos pocos euros. Además, al salir en TV se producen unos picos de carga muy agudos por lo que más valía prevenir que… morir de éxito.

Qué pasó
Pues pasó lo previsible. No soportamos el pico que se produjo, el escalado, añadiendo una máquina por minuto fue demasiado lento y estuvimos caídos durante unos tres minutos. A partir de ahí fuimos remontando y pudimos volver a estar operativos.
A toro pasado parece obvio que las cosas iban a suceder así, pero antes del momento no lo teníamos tan claro.

Conclusiones
Después de soltar la chapa, esta es la parte más interesante del post. Analizando lo sucedido e intentando aprender de los errores, estas son las conclusiones que hemos sacado:

  • Nuestra configuración de auto escalado está bien para el día a día, cuando no sales en prime time en TV pero no es correcta ante grades picos de carga muy agudos.
  • En este tipo de casos hubiera sido mucho más correcto escalar de cinco en cinco máquinas.
  • Tener un único umbral de auto escalado no es suficiente. Si quieres cubrir picos moderados y grandes sin matar moscas a cañonazos lo mejor es establecer tres umbrales: uno que levante una máquina, el segundo que levante dos máquinas y el último que levante cinco. Los valores de los umbrales podrían ser 60, 75 y 90% de carga de CPU aunque habría que verlo en cada caso.

Otro tema importante es cuándo parar las máquinas que se han levantado una vez que pasa el pico de carga. Nosotros paramos una máquina cada tres minutos siempre que la carga de CPU del grupo esté por debajo del 40%. Esto supone parar tres veces más lento que levantamos. Nos pareció un valor correcto aunque no hay ninguna ciencia detrás de ello y todavía tenemos pendiente optimizarlo.

El tema de la escalabilidad me parece apasionante así que iré escribiendo más sobre cómo afrontamos este tema en etece tanto a nivel de software como de hardware.

Programador: medir también es importante


Casi todos los que de una u otra manera nos dedicamos a Internet, tenemos clara la importancia de la analítica web, de medir los más posible y con el mayor detalle posible. Pero existe un colectivo que suele no entender este punto. Ese colectivo son los programadores web, entre los que me incluyo parcialmente.
Desde el punto de vista de un programador, cuando la persona que lleva la analítica web define cómo hay que marcar y etiquetar las diferentes páginas, suele entender que debe hacer cambios en la programación que normalmente ya ha terminado, sin hacer esfuerzo en entender que esos cambios que tiene que hacer suponen una mejora importante para el negocio y que van a permitir entender mucho mejor el comportamiento de los usuarios.
Todo sería mucho más fácil si los programadores entendiéramos desde el principio que la analítica web es una pieza imprescindible, irrenunciable y tan importante como una buena programación. Al igual que poco a poco los programadores incorporamos de manera natural las buenas practicas de SEO, debemos incorporar el etiquetado a nuestras web y cambiarlo tantas veces como sea necesario entendiéndolo como parte de nuestro trabajo. Medir es muy importante!!

Por otro lado, hace tiempo que creo que los equipos que se dedican al SEO deberían estar bajo el paraguas de IT. Pero en el caso de la analítica web, no lo tengo del todo claro. En mi opinión están a caballo entre IT y marketing.

En los próximos años viviremos cambios en las estructuras de los equipos. SEO, analítica e IT estarán juntos y social media estará junto con atención al cliente. Aunque eso es otro tema.