¿”Sandbox” en Google por cambio de diseño?
Escrito por Iñaki | En la categoría General
Como sabéis hace unos meses rediseñamos todas las páginas de rincon y sus galerías de fotos y vídeos. Fue un cambio que no solo buscaba un buen diseño, sino optimizar el rendimiento de la página y su velocidad.
El cambio afectaba a aproximadamente el 80% de nuestras urls y para evitar problemas, se mantuvo el linking tal y como estaba y se respetaron todas las urls.
Además se reordenó el contenido dentro de los propios rincones para que el contenido de calidad apareciese primero, con el objetivo de mejorar la experiencia del usuario.
Con todos estos cambios es de suponer que el cambio no solo no afectaría negativamente a nivel de SEO, sino que con el tiempo supondría una mejora en el posicionamiento.
La sorpresa fue ver que al día siguiente de realizar el cambio comenzamos a perder tráfico procedente de google en la carpeta /rincon/, y dos días más tarde el tráfico procedente de google a esa carpeta es prácticamente nulo (1000-2000 visitas día), llegando únicamente tráfico a los rincones recién creados que posicionaban mucho mejor de lo que lo hacían antes.
Descenso del tráfico en analytics (landing en rincon desde google)
¿Qué había pasado?
Todo un misterio, tras comprobar que todo estaba bien comenté el problema con todas las personas de confianza del mundillo, y nadie vio nada raro.
Todos los rincones nuevos posicionaban. Así que lo único que quedaba era esperar, tras más de dos meses, de un día para otro comenzamos a recuperar tráfico, y en menos de una semana estábamos por encima del tráfico previo a la caída, y desde entonces no ha parado de subir.
Conclusión
A pesar de no haber encontrado ningún otro artículo reportando este caso, la única cosa que se nos ocurre es que existe una especie de sandbox para grandes cambios de diseño y ordenación de contenido.
Resumen:
-Cambio de diseño y reordenación del contenido dentro de las páginas de rincón, galerías, y fotos individuales.
-Ningún cambio en linking, urls o contenidos a excepción del cambio de ordenación.
-Perdida de un día para otro de prácticamente el 100% del tráfico procedente de google en esa carpeta.
-Los rincones que se creaban nuevos posicionando perfectamente en google a pesar de estar en la misma carpeta.
-Tras más de dos meses se vuelve a recuperar el 100% del tráfico en menos de una semana y continúa creciendo por encima de lo que había anteriormente.
¿A alguien más le ha ocurrido o conoce un caso similar?
Error salto de linea usando PHPmailer y SMTP.com
Escrito por Iñaki | En la categoría General
Hoy hemos detectado en minube un error de esos que parecen magia, unos extraños espacios en blanco que aparecían en los emails que enviábamos con PHPmailer a través de SMTP.com
Como es una combinación que puede ser bastante usual y seguro que algún día alguien se encuentra en el mismo problema, vamos a dejar este minipost en el mar de internet para el que lo necesite =)
El problema sucede cuando el html del email contiene más de 990 caracteres seguidos sin saltos de linea (\n o \r), en ese momento, siguiendo el estandar rfc 821 realiza cortes de 1000 caracteres incluyendo el CRLF (\r\n).
Hasta aquí todo parece correcto, enviamos el mail y nos encontramos que realiza unos cortes cada 992 caracteres con un CRLF extraño, que es el que produce el espacio en el email donde no debe estar.
La conclusión es que SMTP.com no cumple con el estandar de corte y que si el tiene que realizar el corte lo hace mal.
La solución es muy sencilla: en la linea 324 de class.smtp.com sustituimos la longitud de corte que está seteada a 998 a 990
Original:
$max_line_length = 998; # used below; set here for ease in change
Cambio:
$max_line_length = 990; # used below; set here for ease in change
Tests A/B con Google Analytics y Custom Variables
Escrito por Iñaki | En la categoría SEO y Analítica
A pesar de que Google tiene una herramienta para realizar test A/B y test multivariable muy potente, hay veces que no se puede usar por algunas limitaciones.
En nuestro caso queríamos realizar test A/B sobre los comparadores de vuelos y hoteles. Estas dos secciones de la web tiene una gran cantidad de JavaScript, post, redirecciones… que no permitían hacer funcionar correctamente los test A/B predefinidos. Además, queríamos mostrárselo solo a una pequeña cantidad de usuarios de nuestra web (supongamos el 10%). Para estos casos la solución más sencilla es utilizar las variables personalizadas de Analytics (Custom Variables).
Las variables personalizadas permiten fijar valores a los usuarios, a las sesiones (navegación por la web) y a las páginas (muy similares a los eventos).
Vamos a fijarnos en el caso concreto del nuevo interfaz del buscador de vuelos. Las variables que nos interesa medir es el porcentaje de clickouts y el número de búsquedas por usuario. La nueva versión se mostrará a un 10% de los usuarios de la web y queremos mantener la coherencia de diseño, de forma que si a un usuario le mostramos un interfaz, siga viéndolo hasta que el test finalice y se descarte, o hasta que los resultados revelen que es el momento de lanzar el nuevo interfaz.
La decisión de que resultados se mostrarán se tomará del lado del servidor, y se guardará en una cookie. A continuación un ejemplo en PHP.
if($_COOKIE['test_vuelos']!=1&&$_COOKIE['test_vuelos']!=2){
$tester = (floor(rand(0,10))==0);
setcookie('test_vuelos',$tester?2:1 , time() + (30 * 86400) );
}
A la hora de decidir mostrar una opción de búsqueda o otra solo tendremos que fijarnos en el valor de la cookie “test_vuelos”, para el 10% de 2 mostraremos la opción de prueba, el otro 90% seguirá viendo el buscador antiguo, pero analizaremos sus datos también para comprobar que el test se desarrolla correctamente.
Ahora identificaremos a los usuarios de ambos test mediante la función _setCustomVar de Analytics. Esta función recibe 4 parametros, el primero es un valor de 1 a 5 que se corresponde con el “slot” de la variable. Tenemos 5 slot disponibles identificados con los números de 1 a 5 (no comienza en 0). Usaremos un slot para cada test que realicemos, por lo que podremos realizar 5 test simultáneos por dominio. El segundo parametro se corresponde con el nombre de la variable, el tercero es el valor que toma la variable (en nuestro caso el número que identifica la versión que se le muestra), y el cuarto identifica el tipo de variable (1=usuario,2=sesión y 3=página).
Para identificar la sesión ejecutaremos el siguiente javascript
_gaq.push(['_setCustomVar',1, 'AB_vuelos', '1',1]);
o en caso de tener el tracking antiguo de google analytics
pageTracker._setCustomVar(1, "AB_vuelos", '1', 1); pageTracker._trackPageview(); //Esta linea solo en caso de que ya hayamos lanzado el evento trackpageview de analytics
Donde 1 es el slot, “AB_vuelos” es el nombre de la variable, ‘1′ es el valor que toma la variable, será ‘2′ en el caso del 10% al que se muestra el test, y el último 1 indica que se trata de una variable de usuario, por lo que se mantendrá entre sesiones a no ser que la cambiemos.
Ahora que tenemos identificados a los usuarios queremos saber cuando hacen una búsqueda, así que, al lanzar la búsqueda, insertamos una customvar de página indicando que se ha realizado la búsqueda. Al igual que en el caso anterior deberemos de cambiar el 3º parámetro e insertar un 2 en caso de ser un usuario de pruebas.
_gaq.push(['_setCustomVar',1, 'busqueda', '1',3]);
o en caso de tener el tracking antiguo de google analytics
pageTracker._setCustomVar(1, "busqueda", '1',3); pageTracker._trackPageview(); //Esta linea solo en caso de que ya hayamos lanzado el evento trackpageview de analytics
Ahora ya sabemos el número de usuarios a los que se ha mostrado cada búsqueda y el número de búsquedas que ha hecho el usuario. Lo siguiente que queremos analizar es el número de clickouts que realizan para obtener porcentajes de conversión.Para ello debemos guardar el número de clicks realizados en los enlaces externos. Con otro evento onclick igual que el anterior lo tenemos solucionado.
_gaq.push(['_setCustomVar',1, 'clickout', '1',3]);
o en caso de tener el tracking antiguo de google analytics
pageTracker._setCustomVar(1, "clickout", '1',3); pageTracker._trackPageview(); //Esta linea solo en caso de que ya hayamos lanzado el evento trackpageview de analytics
Ahora solo nos queda esperar a generar un número significativo de conversiones y compara los ratios usuarios-búsquedas, usuarios-clickouts, y búsquedas-clickouts. Para hacerlo más facilmente podemos crearnos un segmento avanzado de Analytics que sólo incluya las variables personalizadas del slot 1.
Tags: Custom variables, Google Analytics, Test A/B
Recomendaciones Inteligentes usando Strands
Escrito por fillito | En la categoría APIs que usamos
Si habéis estado atentos a los últimos lanzamientos de minube, ya sabréis que esta semana hemos lanzado un nuevo servicio de recomendaciones personalizadas. Ya comentábamos en el blog oficial que para esto usamos la tecnología de Strands. Pero queríamos aprovechar este nuevo lanzamiento, para comentar cómo ha sido la integración desde el punto de vista tecnológico, y además para estrenar una nueva sección en nuestro blog : “APIs que usamos”.
Strands Recommender es uno de los productos de la compañía, que ofrece un servicio de cálculo de recomendaciones personalizadas basadas en la actividad de los usuarios.
Usar ETags para mejorar la performance
Escrito por munix | En la categoría Optimización
Este es mi primer artículo en el blog de los que hacemos minube. Estaba dudando en escribir porque no sabía qué podía aportar que les pudiera servir. Y dándole vueltas a la cabeza me acordé de los protocolos.. y más concretamente del HTTP. Así que hoy les voy a contar un poco acerca de las ETags. Creo recordar que entre las recomendaciones de Google, el uso de ETags está bien visto, porque nos habla de un sitio optimizado. Pero vamos al tema…
ETag. ¿eso con qué se come?
Un ETag no es más que parte de la información que se transmite dentro de las cabeceras (If-None-Match) de las solicitudes de HTTP. Básicamente sirve para indicarle al servidor web qué versión de una página (documento, archivo, etc) tenemos almacenada localmente, para que éste determine si ha cambiado y nos mande nuevamente la página. Es decir. La primera vez que visitamos una página -y si tenemos activada la caché- nuestro navegador la almacena localmente junto a algunos de los recursos adjuntos en dicha página. Para simplificar el concepto voy a ejemplificar con una página como “un todo”, pero el concepto se aplica a cada request que hacemos. Cuando el servidor nos responde con la página nos envía una suma de comprobación o un código identificativo de la versión del documento en cuestión. De esta manera, la segunda vez que pidamos dicho documento, nuestro navegador (o User Agent en general), debería enviar dicho código dentro de las cabeceras. El servidor se encargará de determinar si el documento ha cambiado o si es el mismo. Si no ha cambiado nos devolverá un 304 (Not Modified), en caso contrario nos dará la versión más reciente del documento con su nuevo y respectivo código “de versión”, por llamarle de alguna manera.
Cuando solicitamos un documento por primera vez, el servidor nos devuelve una cabecera como esta:
ETag: "64233457696a7c876b7e"
Y cuando la solicitamos por segunda vez, nosotros enviamos esta cabecera:
If-None-Match: "64233457696a7c876b7e"
Como no ha cambiado la suma el servidor nos devuelve un 304.
Tags: ETags, etags apache, etags con php, http headers, optimización web, protocolo http
Minube usa AWS
Escrito por fillito | En la categoría Arquitectura y Servidores
Hace unas semanas propusimos en twitter que vosotros mismos nos sugirieseis temas sobre los que hablar, y entre las muchas sugerencias que recibimos, ceronne nos preguntó si usábamos Cloud Computing. Así que, como es una de las partes que me toca, he pensado que sería interesante contar qué servicios de Cloud Computing usamos en minube, cómo los usamos y para qué.
Desde nuestros comienzos, una de los grandes problemas a los que nos enfrentábamos era el almacenamiento y procesado de contenido multimedia. Como sabéis, podéis completar un rincón añadiendo material audiovisual, y para nosotros era importante que tanto la experiencia del usuario al publicar su contenido fuera sencilla y rápida, como conseguir una arquitectura fácilmente escalable y manejable. Otro factor añadido, era los recursos económicos limitados. Como toda StartUp, los gastos tienen que ser muy medidos, por lo que un servicio en el que el pago fuera estrictamente por uso nos ayudaría a minimizar gastos. Estaba claro que nuestra mejor apuesta sería el Cloud Computing (pago por uso, fácilmente escalable y transparente para el desarrollador, …)
Cuando lanzamos minube, no había muchas opciones en el mercado, pero una de ellas era Amazon. La tienda online más grande del mundo había lanzado un servicio de Cloud Computing llamado Amazon Web Services. Era la mejor opción en aquel momento y aún sigue siendo la que mejor cubre nuestras necesidades.
Tags: amazon web services, aws, cloud computing, cloud front, ebs, ec2, s3
Descubriendo 404 gracias a Analytics
Escrito por Iñaki | En la categoría SEO y Analítica
Siempre es bueno localizar las paginas que estan dando errores 404, bien para localizar errores en nuestro sitio, o para localizar que nos estan enlazando a una url que no existe y hacerle un 301 a la url correcta, para asi no perder el valor SEO de ese enlace.
Una forma sencilla para tenerlo controlado son los eventos de google Analytics, una herramienta potentísima que utilizamos para muchas cosas.
Simplemente añadiendo en nuestras páginas 404 un pequeño código que localice el referer, la url en la que se está y lance un enlace con estos datos está solucionado. A continuación os pongo un ejemplo en PHP usando el código de seguimiento asíncrono de Analytics (si estas usando el tracking antiguo deberás lanzar los eventos de otra manera).
<script>_gaq.push(['_trackEvent',"E404Control","<?php echo rawurlencode($_SERVER['REQUEST_URI']);?>","<?php echo rawurlencode($_SERVER['HTTP_REFERER']);?>"]);</script>
Como primer parámetro le pasamos la categoría (E404Control), el segundo parámetro será la url en la que estamos (que en Analytics se corresponderá con las Acciones) y como tercer parámetro pasamos el referer.
De esta forma en Analytics podemos localizar el origien de cualquier error desde Contenido>Eventos>Categorias>E404Control>La url que falla>Las url desde las que estamos enlazando esa url.
Tags: Error 404, Google Analytics, javascript, PHP, tracking eventos
minube rumbo al sol naciente
Escrito por fillito | En la categoría minube Asia
Hace casi 9 meses en minube nos embarcamos en la aventura de expander nuestra plataforma al mercado Asiático, un poco inconscientes pero con mucha ilusión.
Y digo inconscientes no porque hubiese sido mejor no hacerlo, todo lo contrario, sino porque en aquel momento éramos totalmente inconscientes de lo que eso iba a suponer a nivel técnico, y el impacto que iba a tener en nuestro código y en nuestra forma de trabajar.
Os voy a contar lo que ha supuesto para nosotros, a nivel de desarrollo, este nuevo lanzamiento:
El primer problema que nos encontramos, el más evidente de todos, era cómo lidiar con nuestra enorme base de datos de ciudades (unas 200.000) y países. En nuestra anterior expansión internacional (Italia, Portugal y Alemania) nos encontramos con el mismo problema, aunque en miniatura. Donde los españoles llamamos “Londres” a la capital británica, un alemán la llama “Londen” y un italiano “Londra”. Con los idiomas asiáticos, por supuesto, ocurre lo mismo, pero con el problema añadido de la grafía. Al final, para Alemania podíamos traducir exclusivamente las pocas decenas ciudades con nombre localizado, pero Madrid seguiría siendo Madrid. Mientras que para Asia nos tuvimos que enfrentar al titánico trabajo de localizar y cambiar grafía a un total de más de 300.000 ciudades, unas 20.000 zonas y unos cuantos cientos de países.
Además de la traducción de toda la web y base de datos, hubieron muchos más contratiempos técnicos. Uno de los más significativos fue el de la codificación de caracteres. A pesar de que somos muy previsores y desde el inicio del proyecto todos los textos se almacenaban formateados en UTF-8, y éste soportar grafía japonesa y china, nos dimos cuenta que la manipulación de cadenas multibyte era algo con lo que no habíamos contado.
Los caracteres e ideogramas asiáticos no caben en un byte, por lo que UTF-8 utiliza entre 2 y 3 bytes para poder representarlos. Esto entra en conflicto con las funciones de manipulación de Strings, que deben tener en cuenta las cadenas de tipo multibyte para no “romperlas”. Adaptar nuestro proyecto al manejo de este tipo de Strings nos supuso repasarnos y modificar las llamadas de unos 1500 archivos.
Por temas de SEO, quisimos construir todas las urls evitando usar caracteres no-románicos. Basicamente, ninguno que no estuviese en los estándares. Para nuestras páginas de destino esto era un gran reto, ya que las urls se deberían construir con nombres romanizados a pesar de tener que mostrar la correcta grafía y traducción. La decisión final fue seguir guardando los nombres originales de destinos junto a su nombre “traducido”, para poder usar uno u otro según convenga. Esto también supuso el repaso y modificación de todo lugar en la web donde se mostrase el nombre de algún destino… os podéis imaginar lo que significa eso…
Para la generación de urls automáticas basadas en textos introducidos por usuarios (nombres de rincones, perfiles de usuario,…), también quisimos mantener la misma política, pero esto era aún más interesante, ya que el control que podríamos tener sobre el texto que se introduciría era nulo.
Para solucionar este problema optamos por crear algún script para “romanizar” los textos orientales. Después de una semana de estudio intensivo sobre grafía y romanización del Chino y Japonés, creamos sendos scripts “Romanizadores” que transliteraban el Chino al PinYin y el Japonés al Romaji (tanto si el texto introducido es Kanji, hiragana o katakana)
Uno de los problemas más gordos, pero más interesantes de solucionar, fué el análisis morfológico de los textos. ¿Para qué? os preguntaréis muchos…
Una de las características tanto del chino como del japonés, es la ausencia de espacios para delimitar las palabras (laescrituraseriaalgocomoestosinningúntipodedelimiadores 
). Si un lector chino/japonés ve un texto, y conoce las palabras, es capaz de indentificarlas, pero para una máquina, la ausencia de delimitadores hace que todo parezca un mismo String. En minube extraemos “tags” y “keywords” de los textos para luego poder lanzar busquedas sobre estas, por lo que para nosotros era imprescindible poder tener delimitadas las palabras.
Después de mucho buscar y leer, dimos con un magnífico proyecto open source llamado mecab, un analizador morfológico de japonés escrito en C. Después de instalarlo como servicio en nuestras máquinas, pudimos empezar a lanzar llamadas de consola que nos devuelven los textos japoneses con sus palabras bien delimitadas 
!!!
Por supuesto, todos estos contratiempos (y otros más…) eran sólo añadidos a las demás tareas unidas al lanzamiento de una nueva versión localizada (repositorio, archivos de configuración, integración de herramientas paralelas, replicación de scripts de cron, etc…)
A pesar de todo esto, que no ha hecho más que hacernos crecer como proyecto y como profesionales, como si fuese un pequeño parto de gemelos, 9 meses de trabajo después, “minube Asia” ya es una realidad.
Por mi parte me encantaría dar las gracias a Raúl por asignarme la responsabilidad de este increíble proyecto, a David Esteban, nuestro nuevo Asian Country Manager, por su incansable ilusión y trabajo, y al resto de mis compañeros desarrolladores por el soporte (en especial a Ivan por su gran apoyo y ayuda con algunas tareas). El proceso ha sido tan grande y complejo que, pensandolo bien, el 100% del equipo de desarrollo ha tenido que participar en algún momento.
Aunque espero que esto de lanzar versiones con distinta grafía no se convierta en una norma … espero que no sea la última versión internacional de minube.
Tags: chino, japones, mecab, multibyte, pinyin, romaji
Hello world!
Escrito por minube | En la categoría Haciendo minube
Como todo tiene que tener un inicio, éste es el nuestro !
Este será a partir de hoy, un canal directo de comunicación con el equipo de desarrollo de minube. Un lugar donde compartir, divulgar nuestras experiencias, descubrimientos y curiosidades que vamos encontrando en el día a día, desarrollando este gran proyecto que no deja de crecer
¿Por qué lo de publicar un blog?
Porque si algo nos gusta, es divulgar y sobre todo compartir. Porque creemos que tenemos muchas cosas que podrían ser interesante contar al mundo, y porque queremos que, a todos los que les apetezca conocer un poco más lo que hay detrás de esta nube verde , tengan dónde hacerlo.
Sólo prometemos mucho código, muchos trucos y consejos, y muchos artículos para todos los geeks y nerds.
No olvidéis seguirnos en twitter !! @minubedev.
exit();