Atraer, Convertir, Sostener
Claves para la rentabilidad de un E-commerce
(Conferencia Sebastian Rodriguez - Nexica)
El éxito en el e-commerce depende de una gran cantidad de factores, que van desde la calidad del producto hasta un marketing inteligente, pasando por la experiencia del usuario y una arquitectura de servidores que permita un crecimiento con costes razonables.
En este seminario queremos ofrecerte una visión global y multidisciplinar de todos los factores que te ayudarán a mejorar la rentabilidad y el éxito de tu negocio en Internet. Analizaremos las herramientas que te permitirán promocionar tu negocio (atraer), convencer a los usuarios de que compren tus productos (convertir) y hacerlo sobre una plataforma tecnológica segura, elástica y eficiente en costes (sostener).
5. Nuestra calificación se establece de forma relativa, por comparación al rendimiento de las demás Webs analizadas por Google (según la fórmula y = 122.32e-0.31x)
7. Nos interesa compararnos con nuestra competencia, con quien compite en resultados por nuestras posiciones.
8.
9. El experimento reveló que no tiene una afectación significativa para los primeros resultados (que tienen altos índices de relevancia por otras métricas), pero que sí puede contar en el “Long Tail”.
10.
11. Impacto en 3 áreas: Experiencia BounceRate http://www.paperstreet.com/blog/2094 Modificaciones a la Web (imágenes) Reducción del tiempo de carga (-200 Kb) http://www.webperformancetoday.com/2010/07/01/the-best-graphs-of-velocity/
12.
13. Representa el porcentaje de usuarios satisfechos según unos umbrales de rendimiento preestablecidos.
14. Partimos del hecho de que no todos nuestros usuarios tendrán el mismo rendimiento (realista en entornos Web)
15. Es una buena herramienta para establecer objetivos de rendimiento en relación a la experiencia de nuestros usuarios.
16. Existen herramientas que y servicios que nos permiten medir el rendimiento en términos de Apdex.http://www.apdex.org/
19. No es una tecnología sino un concepto de negocio. Esto hace que cada proveedor emplee diferentes tecnologías (y puntos de vista) en la materialización de este tipo de servicios.
24. Beneficios del Cloud Agilidad en la Provisión A través de la virtualización (de servidores, redes, almacenamiento) y combinado con paneles de control Self-Service, se reduce la provisión de días a minutos. Pago por Uso Pagar por lo que se consume en cada momento (por horas) elimina la infrautilización de recursos que se daba con el tradicional sobredimensionamiento de las plataformas. Se sustituye CAPEX por OPEX. Elasticidad La capacidad de la plataforma para redimensionar sus recursos en función de la demanda y de la calidad de servicio. Construir plataformas elásticas es mucho más fácil en el Cloud (virtualización, estandarización de servicios, API’s, etc.) Economías de Escala El acceso a recursos compartidos del proveedor nos permite aprovechar economías de escala y acceder a innovaciones a bajo coste.
26. ¿Me conviene el Cloud? Beneficios Cloud ¿Cuál es el patrón de demanda? Variaciones predecibles y periódicas. Ejemplo: Diurno / Nocturo Variaciones puntuales Ejemplo: Presencia en medios ¿Cuál es el tiempo de vida de los servidores? Crecimiento sostenido Demanda constante Horas Días Meses Años
27. ¿Me conviene el Cloud? Beneficios Cloud Capacidad de Autogestión de Servidores y Componentes Administradores de sistemas Desarrolladores Departamentos TI Sin especialización tecnológica Calidad de la Arquitectura SOA Crecimiento Vertical Elasticidad Puntos únicos de Fallo SharedNothing Provisión manual Caching Crecimiento desordenado Stateless Computing Silos Automatización
54. Existen grados de elasticidad dentro de una plataforma. Por lo general, la elasticidad se consigue por capas (servidores web, bases de datos, balanceadores, etc.)
67. Es la arquitectura más comúnmente utilizada en entornos de hosting tradicional.
68.
69. Al introducir el almacenamiento compartido, podemos configurar los servidores para que carezcan de estado (toda la información de configuración, estado y código se almacena en el volumen compartido)
70. De este modo, el despliegue de un nuevo servidor puede ser automático a partir de plantillas estables.
71. Necesitamos un “orquestador” que dimensione los recursos según diferentes inputs (puede ser el propio balanceador o un componente externo)
72.
73. La elasticidad de las bases de datos sólo es habitual en las tecnologías de gama alta (Oracle, SQL Server).
74. Es difícil conseguir este tipo de elasticidad en MySQL. Existen técnicas que reparten la carga, pero no son transparentes para el desarrollador y no escalan linealmente (Master / Slave, Shardening)
75.
76.
77.
78. Podemos renovar constantemente nuestros servidores en cuanto detectamos que se han degradado su rendimientoMean Time ToFailure (MTTF) Mean Time ToRecover (MTTR) Queremos pasar el máximo tiempo posible sin pérdida de dientes Queremos tardar lo menos posible en regenerar el diente que hemos perdido.
82. Reduce los costes del servicio para el proveedor (no necesariamente para el cliente, que debe dedicar un tiempo adicional a la configuración y gestión de su plataforma).
84. Existen grandes diferencias en el grado de implementación del self-service entre los distintos proveedores. Amazon es el ejemplo de una implementación total, mientras que otros proveedores como Telefonica, Terremark o Arsys lo han hecho en menor grado.
85.
86. Self-Service – Por tipo de Cliente Empresas TI Sin personal TI Desarrolladores Departamentos TI Self Service Total Self Service Limitado Gestionado
88. Aceleradores Que nuestra plataforma de alojamiento sea elástica no quiere decir que los servidores sean gratis. ¿Cuántos usuarios puedo servir con cada servidor que pongo en producción? ¿Cuántos de esos usuarios acaban generando ingresos? Con la elasticidad, ahora resulta que un bajo ratio de conversión ya no sólo impacta en mis costes de publicidad, sino también en los de infraestructura! Tengo que maximizar el número de solicitudes (usuarios) que puede atender cada servidor para reducir la necesidad de crecer en servidores. Corolario: Debería invertir más en la infraestructura de los usuarios que genera ingresos que en los que aún no lo han hecho y tienen pocas probabilidades de hacerlo?
106. Asignar un pool de recursos para un perfil determinado de usuario (por ejemplo, los usuarios registrados que hayan realizado compras en el pasado o cualquiera que se encuentre en los pasos finales del funnel de conversión)
107. Monitorizar los tiempos de respuestas de cada nodo y sacar de producción durante cierto tiempo aquellos que no respondan dentro de un tiempo razonable (liberar carga)
108. Está situado en una posición estratégica dentro de la arquitectura para ofrecer servicios de aceleración: Aceleración SSL, Caching. Balanceador S1 S2 S3 S..
116. Crean redes de contenido que se sincronizan con los servidores del cliente y actúan como una caché intermedia desde servidores más próximos al usuario final.
117. Son una medida muy efectiva para webs con grandes volúmenes de tráfico y alcance global. Sus beneficios crecen a medida que lo hace el alcance geográfico del cliente (y viceversa)
122. Las diferencias de precio son muy grandes. Akamai domina el mercado de “gama alta”, aunque hay otros actores con una calidad similar y mejores precios.
123.
124.
125. Confíe en especialistas para diseñar su arquitectura. Implique desde el primer día a los desarrolladores en el diseño de la arquitectura y asegure una buena comunicación entre quien operaciones y desarrollo (google:DevOps).
126. La estrategia de caching es uno de los factores más cruciales de la arquitectura y el que requiere más implicación de los desarrolladores (puede no ser transparente)
127. Optimice el rendimiento de sus servidores (web, base de datos) optimizando su código y utilizando aceleradores (muchos son transparentes, plug&play)
128. Monitorice constantemente el rendimiento de sus aplicaciones. Es posible perder todo el trabajo de optimización si nadie controla el rendimiento de las aplicaciones a lo largo de su evolución.