Métrica. Evaluación de la eficacia de una campaña publicitaria. Trabajar en el nuevo Yandex Metrica: instrucciones para análisis web

En este artículo quiero analizar algunas de las métricas de control de calidad más importantes en mi opinión. Estos serán indicadores, coeficientes e indicadores que le permitirán captar una imagen general de lo que está sucediendo en el proyecto en términos de calidad y determinar los pasos para mejorarlo. Las métricas cubrirán cinco áreas diferentes: requisitos, calidad del software, efectividad del equipo de pruebas, calidad del trabajo de control de calidad y retroalimentación. Es importante medir y rastrear indicadores simultáneamente en varias secciones del proceso de desarrollo de software para detectar problemas comunes y raíz y poder configurar y optimizar todo el proceso.

Grupo 1 - Requisitos para el software que se está desarrollando

Este grupo de métricas nos permitirá evaluar qué tan bien hemos elaborado los requisitos (historia de usuario) del software, identificar vulnerabilidades y las características de software más complejas y potencialmente problemáticas, y comprender dónde se requiere un control especial:

1. Requisitos de cobertura de la prueba

En otras palabras, este es el número de pruebas por requisito.

Propósito de la métrica: identificar debilidades en la cobertura de las pruebas y resaltar los riesgos.

• Por supuesto, esta métrica sólo funcionará si los requisitos están bien descompuestos y son más o menos equivalentes. Por supuesto, esto no siempre es posible, pero si puede hacer que los requisitos sean lo suficientemente atómicos, esta métrica mostrará la desviación de la cobertura de cada requisito del nivel promedio. Cuanto más difiere el valor de 1, se escriben menos o más pruebas de lo habitual para un requisito.
• Lo más importante a lo que hay que prestar atención son los requisitos para los cuales el coeficiente será igual o cercano a 0. Para estos, es necesario considerar agregar pruebas.
• Si los requisitos no son atómicos, entonces esta métrica solo garantizará que haya al menos una prueba para cada requisito. Para ello el coeficiente siempre debe ser mayor que 0.

2. Grado de interconexión de los requisitos

La métrica se calcula como el número promedio de conexiones de cada requisito con otros requisitos.

Propósito de la métrica: Proporcionar una base para evaluar el momento de las pruebas y tener en cuenta los posibles riesgos. Conociendo el grado de influencia mutua de los requisitos entre sí, puede, por ejemplo, planificar tiempo y casos adicionales para pruebas de un extremo a otro, trabajar en comprobaciones de regresión, mirar hacia la integración, etc.

• El valor de esta métrica oscilará entre 0 y 1. 1 significa que cada requisito está relacionado con cada uno y 0 significa que no existe relación.
• Es difícil introducir restricciones sobre los valores de este coeficiente; mucho depende de las características específicas de la funcionalidad, la arquitectura y las tecnologías. Sin embargo, por mi propia experiencia puedo decir que es bueno cuando el grado de conectividad no supera los 0,2-0,3. De lo contrario, la modificación en el marco de uno de los requisitos dará lugar a una cadena de cambios y, por tanto, a posibles errores en una parte importante del producto.

3. Factor de estabilidad de requisitos

Propósito de la métrica: muestre cuántos requisitos ya implementados deben rehacerse de una versión a otra al desarrollar nuevas funciones.

• Por supuesto, no existe una funcionalidad completamente aislada, pero el número de requisitos nuevos debe prevalecer sobre los cambiantes y el coeficiente debe ser preferiblemente inferior a 0,5. En este caso, introducimos el doble de funciones nuevas que reelaboramos las existentes.
• Si el coeficiente es superior a 0,5, especialmente si es superior a 1, lo más probable es que esto signifique que anteriormente hicimos algo que resultó innecesario. El equipo no se centra en crear nuevos valores comerciales, sino en reelaborar funciones lanzadas anteriormente.
• La métrica también da una idea de la facilidad con la que se puede escalar la funcionalidad del sistema y agregar nuevas funciones.

Grupo 2 - Calidad del producto que se desarrolla

Como sugiere el nombre, este grupo de métricas demuestra la calidad del software, así como la calidad del desarrollo en sí.

1. Densidad de defectos

Se calcula el porcentaje de defectos por módulo individual durante una iteración o lanzamiento.

Propósito de la métrica: resalte qué parte del software es la más problemática. Esta información ayudará a evaluar y planificar el trabajo con este módulo, así como en el análisis de riesgos.

• Las razones de una gran cantidad de defectos en cualquier módulo específico (coeficiente superior a 0,3) pueden ser diferentes: requisitos de calidad deficientes, calificaciones de los desarrolladores, complejidad técnica, etc. En cualquier caso, esta métrica llamará inmediatamente nuestra atención sobre el área del problema.

2. Coeficiente de regresión

Propósito de la métrica: muestre dónde se gastan los esfuerzos del equipo: ¿estamos más involucrados en la creación y depuración de nuevas funciones o nos vemos obligados a parchear partes existentes del software la mayor parte del tiempo?

• Cuanto más cerca esté el coeficiente de 0, menos errores se introdujeron en la funcionalidad existente al implementar nuevos requisitos. Si el valor es superior a 0,5, dedicamos más de la mitad de nuestro tiempo a restaurar funciones del software que funcionaban anteriormente.

3. Tasa de defectos reabiertos

Propósito de la métrica: evaluar la calidad del desarrollo y la corrección de defectos, así como la complejidad del producto o módulo individual

• Esta métrica se puede calcular para todo el software, módulo individual o funcionalidad. Cuanto más cercano a 0 esté el valor resultante, menos errores antiguos se repetirán durante el desarrollo.
• Si el coeficiente resulta ser superior a 0,2-0,3, esto puede indicar la complejidad técnica del módulo y los requisitos altamente relacionados que contiene, o una arquitectura torpe, o que la solución anterior se realizó mal.

4. Costo promedio de arreglar un defecto

La relación entre el monto de los costos incurridos por el equipo al trabajar con todos los defectos (por ejemplo, como parte de una versión) y el número total de defectos.

Propósito de la métrica: muestran lo caro que nos resulta detectar y corregir cada defecto. Esto permitirá calcular los beneficios de reducir el número de errores cometidos y evaluar la viabilidad de las técnicas adecuadas.

• Por supuesto, aquí no existen valores correctos; todo estará determinado por las características específicas de una situación particular;

5. Número de defectos en el código de un desarrollador específico

Propósito de la métrica: resaltar posibles dificultades en el equipo de desarrollo, qué especialistas carecen de experiencia, conocimiento o tiempo y necesitan ayuda.

• Si, por ejemplo, el 50% de todos los defectos son responsabilidad de 1 desarrollador y hay 5 de ellos en el equipo, entonces claramente hay un problema. Esto no significa que este programador no funcione bien, pero indica que es imperativo comprender las razones de esta situación.
• La métrica, entre otras cosas, puede ser un indicador de un módulo/funcional/sistema particularmente difícil de desarrollar y soportar.

Grupo 3: Capacidad y eficacia del equipo de control de calidad

El objetivo principal de este grupo de métricas es expresar en números de lo que es capaz el equipo de pruebas. Estos indicadores se pueden calcular y comparar periódicamente, se pueden analizar tendencias y se puede observar cómo el trabajo del equipo se ve afectado por ciertos cambios.

1. Velocidad del equipo de control de calidad

Se calcula como la relación entre los puntos de la historia implementados (o requisitos, o historias de usuarios) en varias, por ejemplo, 4-5 iteraciones (Sprint) con respecto al número de iteraciones seleccionadas.

Propósito de la métrica: Expresar numéricamente las capacidades y la velocidad del trabajo del equipo para una mayor planificación del alcance del trabajo y el análisis de las tendencias de desarrollo.

• La métrica le permite monitorear la velocidad del trabajo de control de calidad y observar qué procesos internos o influencias externas en el equipo pueden afectar esta velocidad.

2. Vida media de los defectos

El tiempo total durante el cual los defectos encontrados dentro de una iteración o versión estuvieron abiertos a la suma de defectos.

Propósito de la métrica: muestra cuánto tiempo se tarda en promedio en trabajar con un defecto: registrarlo, corregirlo y reproducirlo. Este indicador le permitirá estimar el tiempo necesario para las pruebas y resaltar las áreas del software con las que surgen las mayores dificultades.

• Normalmente, la vida útil de un defecto es el tiempo completo desde su creación (estado Creado) hasta su cierre (Cerrado), menos todos los posibles Pospuestos y Retenidos. Cualquier rastreador de errores le permite calcular y cargar esta información para un sprint o lanzamiento por separado.
• Además, la vida media de un defecto se puede calcular para varios módulos y funciones de software o, lo que es más interesante, por separado para cada uno de los evaluadores y desarrolladores del equipo. Esto le brinda la oportunidad de identificar módulos particularmente complejos o un eslabón débil en el equipo de software.

Grupo 4 - Calidad del trabajo del equipo de pruebas.

El propósito de este conjunto de métricas es evaluar qué tan bien los evaluadores realizan sus tareas y determinar el nivel de competencias y madurez del equipo de control de calidad. Al tener este conjunto de indicadores, puede comparar el equipo consigo mismo en diferentes momentos o con otros grupos de prueba externos.

1. Eficiencia de las pruebas y casos de prueba.

Propósito de la métrica: muestre cuántos errores en promedio nuestros casos pueden detectar. Esta métrica refleja la calidad del diseño de la prueba y ayuda a monitorear la tendencia de su cambio.

• Es mejor calcular esta métrica para todos los conjuntos de pruebas: para grupos separados de pruebas funcionales, conjuntos de regresión, pruebas de humo, etc.
• Este indicador de "letalidad" de las pruebas permite monitorear la efectividad de cada uno de los kits, cómo cambia con el tiempo y complementarlos con pruebas "nuevas".

2. Tasa de errores omitidos por producción

Número de errores descubiertos después del lanzamiento \ número total de errores en el software descubiertos durante las pruebas y después del lanzamiento

Propósito de la métrica: demostrar la calidad de las pruebas y la eficiencia de la detección de errores: qué proporción de defectos se filtraron y qué proporción pasó a producción.

• El porcentaje aceptable de errores que se omitieron en la producción dependerá, por supuesto, de muchos factores. Sin embargo, si el coeficiente es >0,1, esto es malo. Esto significa que durante las pruebas no se detectó uno de cada diez defectos y provocó problemas en el software ya distribuido a los usuarios.

3. Tiempo real dedicado por el equipo de control de calidad

La relación entre el tiempo dedicado por el equipo directamente a las actividades de control de calidad y el número total de horas.

Propósito de la métrica: en primer lugar, aumentar la precisión de la planificación y, en segundo lugar, monitorear y gestionar el desempeño de un equipo en particular.

• Las actividades objetivo incluyen análisis, diseño, evaluaciones, pruebas, reuniones de trabajo y mucho más. Los posibles efectos secundarios son tiempo de inactividad debido a bloqueadores, problemas de comunicación, falta de disponibilidad de recursos, etc.
• Naturalmente, este coeficiente nunca será igual a 1. La práctica muestra que para equipos efectivos puede ser 0,5-0,6.

4. Precisión de la estimación del tiempo por área\tipos\tipos de trabajo

Propósito de la métrica: permite el uso de un factor de corrección para evaluaciones posteriores.

• El grado de precisión de la evaluación se puede determinar para todo el equipo o para los evaluadores individuales, para todo el sistema o para módulos de software individuales.

5. Proporción de defectos no confirmados (rechazados)

Propósito de la métrica: muestre cuántos defectos se crearon "inactivamente".

• Si el porcentaje de defectos rechazados supera el 20%, entonces el equipo puede experimentar una desincronización al comprender qué es un defecto y qué no.

Grupo 5 - Comentarios y satisfacción del usuario

Y finalmente, un grupo de métricas que muestran cómo el producto fue aceptado por los usuarios finales, qué tan bien cumplió con sus expectativas. Pero no sólo la retroalimentación del software es importante: otra tarea importante de este grupo de métricas es mostrar si los usuarios están satisfechos con el proceso de interacción con el equipo de TI en general y con el control de calidad en particular.

1. Satisfacción del usuario con los servicios de TI

Encuesta periódica de satisfacción de los usuarios con los servicios TI con puntuación.

Propósito de la métrica: mostrar si los usuarios confían en el equipo de TI, si entienden cómo y por qué está organizado su trabajo y en qué medida este trabajo cumple con las expectativas.

• La métrica puede servir como indicador de que es necesario centrarse en optimizar el proceso o hacerlo más claro y transparente para los usuarios.
• El indicador de satisfacción se puede calcular en función de los resultados de una encuesta posterior al lanzamiento. Recopilamos todas las calificaciones y calculamos la puntuación media. Esta puntuación se puede volver a calcular después de realizar cambios en el proceso.

2. Satisfacción del usuario con el producto

Encuesta periódica a los usuarios sobre su grado de satisfacción con el producto.

Propósito de la métrica: determinar qué tan bien el producto que se está desarrollando cumple con las expectativas del usuario, si nos estamos moviendo en la dirección correcta, si determinamos correctamente la importancia de las características y elegimos las opciones de solución.

• Para calcular esta métrica, también realizamos una encuesta a los usuarios y calculamos la puntuación media. Al calcular este indicador periódicamente (por ejemplo, después de cada lanzamiento), puede controlar la tendencia en la satisfacción del usuario.

3. Participación de las partes interesadas

Número de iniciativas y propuestas para mejorar el proceso y producto recibidas durante la iteración (lanzamiento) de las partes interesadas

Propósito de la métrica: determinar el grado de participación de las partes interesadas externas en el trabajo sobre el producto. Teniendo esa métrica a mano, puedes navegar hacia donde necesitas obtener retroalimentación para que algún día no enfrentes desprecio y odio, problemas y malentendidos.

¡Nuevas colecciones de materiales para descargar! Hemos recopilado paquetes de materiales sobre temas actuales, incluidas presentaciones de expertos, seminarios web, artículos, ejemplos de implementación, etc.
Para descargar materiales, haga clic en el botón correspondiente:

El estándar más conocido y utilizado para organizar los procesos de control de calidad es la serie de normas ISO 9000. Para el proceso de desarrollo de software, se utiliza la norma ISO 9001, que incluye el diseño por producción. Cabe señalar que este estándar es difícil de utilizar directamente en la gestión de la calidad del desarrollo de software, ya que inicialmente está enfocado al desarrollo de productos industriales. Especialmente para apoyar los procesos de desarrollo de sistemas de software por parte de la organización ISO, se ha desarrollado la guía ISO 9000-3, que formula los requisitos del modelo de calidad ISO 9001 para organizar el proceso de desarrollo de software.

Por tanto, los requisitos de la norma ISO 9000-3 se pueden utilizar para evaluar la calidad del proceso de desarrollo en la propia organización o en la organización de contratistas. Actualmente, la versión 2000 del estándar se está utilizando en todas partes, en la que el control de procesos está a la vanguardia, sin embargo, en esta versión del estándar no hay ninguna especificidad relacionada con el desarrollo de software.

Una desventaja de la norma ISO 9000 es la dificultad de medir el nivel de calidad de un proceso de desarrollo de software según el modelo de calidad propuesto.

Entre los desarrolladores de software, especialmente en el extranjero (principalmente en EE. UU.), un modelo de calidad alternativo goza de gran popularidad: CMM - SEI. Este modelo de calidad fue desarrollado en el Instituto de Ingeniería de Software bajo el patrocinio del Departamento de Defensa de Estados Unidos. Inicialmente, este modelo de calidad fue utilizado por organizaciones gubernamentales, en particular militares, al realizar pedidos de desarrollo de software. Actualmente, el estándar se utiliza ampliamente para analizar y certificar los procesos de desarrollo de software de empresas que producen software complejo en áreas de aplicación críticas. Las ventajas importantes del modelo CMM son el anidamiento jerárquico de modelos de calidad, que permite medir y comparar los niveles de calidad de los procesos en diferentes organizaciones y garantizar una mejora efectiva de la calidad de los procesos.

ISO también ha desarrollado un modelo de calidad para medir y mejorar la calidad.

En cierto sentido, los modelos de calidad CMM e ISO son intercambiables, sin embargo, en esencia, no se contradicen, ya que se basan en el mismo paradigma de calidad: TQM - Total Quality Management.

Es importante señalar que el simple hecho de tener un proceso de desarrollo de software que cumpla con un alto nivel de calidad no garantiza un producto de alta calidad. Tener un proceso de calidad significa que la calidad del producto resultante mejorará constantemente una y otra vez. Por tanto, a la hora de tomar decisiones es necesario tener en cuenta el tiempo durante el cual se encuentra instalado y operativo un proceso del nivel de calidad requerido en un área tecnológica determinada. Sin embargo, la falta de información sobre la calidad del proceso hace que la calidad del producto que se desarrolla sea impredecible.

Calidad del producto software

Calidad de los componentes del software.

El desarrollo de grandes sistemas de software modernos se basa cada vez más en el desarrollo de componentes (Component Base System - CBS). La tecnología de construcción CBS puede reducir significativamente el costo y el tiempo de desarrollo. Al mismo tiempo, aumenta el riesgo asociado al uso en el sistema de componentes de software desarrollados por diferentes fabricantes.

La forma más efectiva de resolver este problema es utilizar métricas para gestionar la calidad y los riesgos al construir CBS, con el fin de medir varios factores que afectan la calidad final del producto y eliminar fuentes de riesgo. En este caso, se deben utilizar métricas de calidad para respaldar la toma de decisiones en varias etapas del ciclo de vida del desarrollo sobre la viabilidad económica del uso de componentes.

Los códigos fuente de los componentes suelen ser inaccesibles para los diseñadores de sistemas, además, proporcionan una interfaz estructurada compleja. La consecuencia de esto es que existe una diferencia significativa entre las métricas que normalmente son aplicables a los sistemas tradicionales y las de CBS. La mayoría de las métricas tradicionales se utilizan durante la fase de planificación y desarrollo. La clave para la gestión de la calidad cuando se utilizan métricas en el desarrollo de sistemas de componentes es la selección de métricas de calidad que sean aplicables en todas las etapas del ciclo de vida y evalúen tanto la calidad del proceso como la calidad del producto.

Saludos amigos. Después de una larga etapa de desarrollo y pruebas beta aún más largas, el nuevo Yandex Metrica 2.0 está emergiendo de las sombras. A partir del 22 de junio se convertirá en la principal herramienta para recopilar y analizar estadísticas, mientras que la versión anterior se transferirá al subdominio old.metrika.yandex.ru, donde vivirá sus últimos meses.

Estoy encantado con Yandex Metrika Beta, aunque me llevó algún tiempo profundizar en él y comprender sus capacidades. Pero vale la pena: al menos encontré algunas cosas que ni la versión actual ni Analytics pueden hacer.

En realidad, en este material intentaré analizar el proceso de trabajo para usted, redactar instrucciones para análisis web en el nuevo Yandex Metrica, ya que es algo diferente de su predecesor y puede causar disonancia cognitiva en el primer contacto.

- Así que mira la métrica beta.
- No quiero, le tengo miedo.

Conversación con un especialista en SEO conocido.

Entonces primero la parte conceptual. ¿Cual es la diferencia principal? Old Metrica es principalmente un conjunto de sectores (informes) ya preparados para su análisis. Configurarlos y crear tus propios sectores es difícil e inconveniente. Por eso, para muchos, este proceso consiste únicamente en trabajar con “Objetivos”, que, afortunadamente, están destinados a algo completamente diferente, y los “Informes” quedan en algún lugar por ahí, en un estante polvoriento, fuera de los corchetes.

La actual ya es una plastilina completa que le permite personalizar absolutamente cualquier sección según sus necesidades, configurar los datos iniciales, filtrar lo innecesario y seleccionar una opción conveniente para la presentación de datos. Personalice completamente su espacio de trabajo, lo cual es especialmente apreciado por los especialistas en marketing de Internet.

Y ahora en orden

Por el momento, la versión beta todavía se encuentra en https://beta.metrika.yandex.ru/ y la vista de la lista de sitios no ha sufrido cambios fundamentales, con la excepción de algunas adiciones y el porcentaje mostrado de crecimiento relativo del tráfico. al día anterior, que ahora con tanto cuidado han eliminado de la versión antigua (dicen, vamos, sigue adelante, acostúmbrate).

El nuevo sistema de etiquetas y el panel de acceso rápido son muy convenientes. Le permite crear varias etiquetas en el panel de definición de etiquetas y asignar una o más de ellas a cada sitio (de hecho, incluirlas en grupos de estas etiquetas). Luego, al seleccionar la opción del mismo nombre en el panel de definición de etiquetas, muestra los grupos a los que accedes con más frecuencia en el panel de acceso rápido. Además, al visualizar uno de los grupos, se presentarán estadísticas resumidas de tráfico de los sitios incluidos en él.

Pero una vez que pasas a un mostrador separado, puedes empezar a perderte. Miremos la interfaz.

Menú de la nueva interfaz Yandex Metrika

Los elementos del menú superior no necesitan presentación, pero sí la estructura y algunos elementos del menú de la izquierda. Primero que nada, lo que sabemos:

• Resumen: la página principal del contador del sitio.
• Mapas: mapas de clics, desplazamiento, enlaces y análisis de formularios. En general, la mayoría del contenido del elemento "Comportamiento" es la versión anterior.
• Configuración: en realidad, la configuración del contador actual de Yandex Metrics.

Pero el último elemento, "Informes", es la piedra angular de la herramienta actualizada.

• Mis informes son todos los sectores que creó y guardó.
• Los elegidos son lo mismo, solo que los elegidos (despierta, Neo).
• Informes estándar: aquí es donde se encuentran todas las secciones antiguas y dolorosamente familiares. Volveremos a ellos más adelante en el material.

Interfaz de la página principal del contador

El constructor de la página de inicio es similar al del antiguo Yandex Metrica, pero, a diferencia de este último, es más ergonómico y tiene un impresionante conjunto de widgets listos para usar. Bueno, aquí también se hace sentir la flexibilidad de configuración de segmentos inherente a la nueva versión.

Puede seleccionar un widget ya preparado de la biblioteca o crear uno nuevo: indicador, gráfico circular, gráfico o tabla de datos. Personalice una porción de la información que se muestra en ellos y fíjela en la parte deseada de la pantalla de resumen usando un simple botón de colocar.

Trabajar con segmentos en Yandex Metrica

Entonces, llegamos a lo principal: una descripción del esquema de generación de informes. En primer lugar nos dirigimos a los informes estándar mencionados anteriormente (“Reportes” - “Informe Estándar”) y seleccionamos la información que luego segmentaremos. Por ejemplo, "Fuentes" - "Fuentes, resumen".

Y ahora comenzamos a seleccionar sólo aquellas visitas que queremos analizar. Por ejemplo, queremos saber la cantidad de personas que visitaron el sitio desde una tableta desde el motor de búsqueda Yandex para una consulta que incluía la palabra "SEO". Para ello, configuramos tres niveles de segmentación:

• “Segmento” - “Tecnologías” - “Dispositivos” - en la ventana de opciones que se abre, seleccione “Tabletas”.
• "Segmento" - "Fuentes" - "Última fuente" - "Buscar" - "Motor de búsqueda" - en la ventana de opciones que se abre, seleccione "Yandex".
• “Segmento” - “Fuentes” - “Última fuente” - “Buscar” - “Frase de búsqueda” - en la ventana que se abre, ingrese *SEO* (los operadores de asterisco indican cualquier conjunto de caracteres en ambos lados de esta palabra).

Total: los gráficos y la tabla con la información quedarán reordenados como necesitemos, listos para su descarga o análisis. Sobre la marcha, puede cambiar, eliminar o agregar nuevos niveles de refinamiento; la información mostrada se actualizará sobre la marcha.

Aquí podemos comparar el segmento resultante con otro, utilizando la herramienta “Comparar Segmentos” - “Especificado Manualmente”. Sin embargo, no podemos cambiar la composición del segmento, sino simplemente comparar varios períodos de un segmento usando la opción “Período anterior”.

Aquí tampoco se han olvidado los viejos “Objetivos”, que podemos utilizar como otro parámetro clarificador para construir un segmento.

La cantidad de opciones para construir segmentos es prácticamente ilimitada. A continuación, podemos analizar la información recibida y olvidarnos de la selección, o guardarla y acceder a ella más tarde desde el menú “Informes” - “Mis Informes”, o simplemente subir los datos.

Métricas de Yandex del webvisor

El proceso de segmentación anterior resultó muy útil para esta herramienta. Seleccionar registros de visitas a grupos de usuarios de interés se ha vuelto aún más fácil. El procedimiento es el mismo: vaya a "Webvisor", configure un segmento (o cárguelo desde los guardados) y mire.

Aquí termino esta instrucción de revisión y, como siempre, espero sus preguntas en los comentarios.

Hemos publicado un nuevo libro, Marketing de contenidos en redes sociales: cómo entrar en la cabeza de sus seguidores y hacer que se enamoren de su marca.

Suscribir

Creemos un informe. En las métricas, seleccione "Lograr objetivos" - "El objetivo para el que ha establecido la conversión". Suele ser una página de "Gracias por su compra".

Como resultado, obtendremos datos sobre cuántas compras se realizaron en cada República de Kazajstán y cuánto se gastó en atraer a los usuarios que las realizaron. Divida la cantidad de conversiones por el costo de los clics para obtener el costo de un cliente potencial. Si lo tiene configurado, puede agregar una columna de "Ingresos" para estimar la ganancia recibida.

Segmentos para retargeting y ajustes de ofertas: un nuevo nivel de relación con compradores potenciales

En esta sección, crearemos y guardaremos Yandex.Metrics y definiremos los ajustes que se utilizarán al configurar campañas en Direct.

Recuerde fijar el periodo de tiempo para que la muestra sea representativa. Es necesario que los datos se construyan en base al comportamiento de un gran grupo de visitantes.

Género y edad – ajuste

Después de crear este informe, podremos ver quién compra mejor en nuestro sitio, hombres o mujeres, y cuál es la edad de dichos compradores. Después de esto, nada nos impedirá ajustar las tarifas para este segmento.

Seleccione: “Reportes” – “Visitantes” – “Género” (1).

Como resultado, hacemos ajustes para las mujeres. Al mismo tiempo, los datos obtenidos nos ayudaron a ver que los representantes del sexo más fuerte también pasan tiempo en nuestro sitio web. Necesitas trabajar con esta información. Por ejemplo, escriba anuncios relevantes.

Hora y reloj - ajuste

Sus visitantes pueden tener diferentes actividades durante el día o la semana, por lo que en este punto identificaremos los días y horas de mayor conversión para su recurso, después de lo cual podrá establecer ajustes de tiempo en Direct.

“Informes” – “Visitantes” – “Asistencia por hora del día”.

En las agrupaciones agregamos: Comportamiento: fecha y hora – “Fragmentos de fecha/hora” – “Día de la semana de visita” (2). Seleccione un objetivo y ordénelo por conversión. Recibimos un informe que muestra en qué día y a qué hora la conversión es máxima.

Geografía

“Informes” – “Visitantes” – “Geografía”.

El informe ayudará a los sitios a identificar regiones que se venden mejor que otras. Normalmente, en muchos nichos, la mayor parte de las ventas proviene de Moscú o San Petersburgo y sus regiones. Por lo tanto, la mayor parte de los anunciantes dividen su República de Kazajstán en ciudades federales y el resto de Rusia.

El informe geográfico le ayudará a encontrar un curso para una mayor fragmentación de las campañas en Direct o identificar campañas publicitarias regionales con rendimientos débiles.

Segmento “Carrito olvidado”

Creamos: “Reportes” – “Visitantes” – “Tiempo desde la primera visita”.

Para los objetivos, seleccionaremos un objetivo macro: compra, cita para una consulta en la oficina, etc. Ordenamos por conversión. Seleccione las primeras 2 líneas para trazar el gráfico. Como resultado, obtendremos información sobre cuánto tiempo dedican nuestros clientes a pensar en su decisión de compra. Además, podremos utilizar datos en la interfaz de Direct para evitar mostrar publicidad a quienes ya no necesitan nuestra oferta.

Del informe vemos que el objetivo se logra principalmente el día de la visita, pero a lo largo del mes los usuarios regresan y realizan conversiones.

Ahora el segmento en sí. Lo crearemos para aquellos que dejaron el artículo en el carrito pero nunca lo compraron.

Vayamos al ya familiar informe "Fuentes" - "Resumen", dejemos una marca de verificación solo en la columna "Conversiones publicitarias", haga clic en + y seleccione en el menú: "Comportamiento" - "Lograr objetivos" - "Objetivo: agregado al carrito "(El objetivo de JavaScript debe configurarse en los botones "Agregar al carrito"). Guardamos y nombramos el segmento, ahora vamos a Directo.

Buscamos el anuncio que queremos mostrar a este segmento, hacemos clic en “Condiciones de selección de audiencia”, luego en “Agregar condición”.

Informes para análisis de sitios web: estudiar y mejorar

Visor web

Sus datos nos ayudarán a identificar las debilidades del sitio y comprender las dificultades que encuentran los usuarios.

Veamos los segmentos de visitas de Webvisor en los que se logró nuestro objetivo macro.

Tomemos una muestra y veamos cómo lo lograron los usuarios. Quizás comprendamos patrones de comportamiento de nuestros clientes que no conocíamos. ¿Qué pasaría si, antes de realizar un pedido, la mayoría de ellos mirara un álbum de fotos o interactuara con elementos interactivos en el sitio y tal vez pasara mucho tiempo leyendo reseñas? Estos datos le ayudarán a decidir cómo colocar y diseñar correctamente los bloques en el sitio.

El segundo segmento son los usuarios que pasaron suficiente tiempo en nuestro sitio web para realizar una compra, pero nunca la realizaron. El análisis de dichas visitas permitirá conocer los principales desafíos a los que se enfrentan los visitantes.

Desplazarse/hacer clic en mapas

Un mapa de desplazamiento le ayudará a comprender en qué pantalla pasan más tiempo sus visitantes. Quizás alguna información necesaria que ayudará a tomar una decisión de compra esté en la “zona fría” y deba trasladarse a otro lugar. Por ejemplo, a un cliente se le anuncia solo para solicitudes que indican una estación de metro, y en la parte inferior de la página se encuentra un mapa con una dirección e indicaciones.

El resultado es un alto porcentaje de rechazos, porque la ubicación de la oficina de la organización es importante para los clientes que vienen con este tipo de solicitudes.

Durante medio siglo de investigación, la industria del software moderna ha acumulado una impresionante colección de modelos y métricas que evalúan la producción individual y las propiedades operativas del software. Sin embargo, la búsqueda de su universalidad, el hecho de no tener en cuenta el ámbito de aplicación del software que se está desarrollando, ignorar las etapas del ciclo de vida del software y, finalmente, su uso irrazonable en diversos procedimientos de toma de decisiones de producción han socavado significativamente la confianza. de desarrolladores y usuarios de software en los mismos.

Sin embargo, un análisis de la experiencia tecnológica de los líderes en producción de software muestra lo costosa que es por la imperfección de una previsión no científica de la solvencia y los costos laborales, la complejidad de los programas, la inflexibilidad del control y la gestión de su desarrollo, y mucho más, lo que indica la falta de soporte metodológico de extremo a extremo y, en última instancia, conduce al incumplimiento de los requisitos del usuario, el estándar requerido y la posterior reelaboración dolorosa y que requiere mucho tiempo. Estas circunstancias requieren una cuidadosa selección de técnicas, modelos y métodos para evaluar la calidad del software, teniendo en cuenta las limitaciones de su idoneidad para varios ciclos de vida y dentro del ciclo de vida, estableciendo un procedimiento para su uso conjunto, el uso de multimodelo redundante. investigación de los mismos indicadores para aumentar la confiabilidad de las evaluaciones actuales, acumulación e integración de información métrica diversa para la toma oportuna de decisiones de producción y certificación del producto final.

A continuación, en la Tabla 1.3, se muestran modelos y métricas que han demostrado su eficacia en la evaluación de la calidad del software, adecuados para predecir y determinar varios indicadores de complejidad y confiabilidad del programa.

Tabla 1.3.

Nombre del modelo	Fórmula, designación
Métricas de complejidad
Métricas de Halstead Duración del programa; Alcance del programa Evaluación de su implementación; Dificultad para entenderlo; Codificación intensiva en mano de obra; Nivel de lenguaje de expresión; Contenido de informacion; Modularidad óptima;	norte = norte 1 registro 1 norte 1 + norte 2 registro 2 norte 2 L * = (2 norte 2)/ (norte 1 norte 2) re = (norte 1 norte 2) (2norte 2) = 1/ l * * = V/ D 2 = V/ L * 2
Métricas de Gilba Número de declaraciones de bucle; Número de declaraciones de condición; Número de módulos o subsistemas; La relación entre el número de conexiones entre módulos y el número de módulos; La relación entre el número de resultados anormales de un conjunto de operadores y el número total de operadores;	f = N 4 SV / L mod f*=N*SV/L
Métricas de McCabe número ciclomático; Complejidad ciclomática;	(GRAMO) = metro – norte + p (G) = (G) +1 = metro – norte + 2
Métrica de Chepin Una medida de la dificultad de comprender programas basados ​​en datos de entrada y salida;	H = 0,5T+P+2M+3C
Métrica de Schnadewied Número de rutas en el gráfico de control.
Métrica de Myers Medida de intervalo;
Métrica de Hansen Par (número ciclomático, número de operadores)
La métrica de Chen La medida topológica de Chen;	METRO(G) = ((G), C, Q 0)
Métrica de Woodward Medida nodal (número de nodos de transmisión de control);
Métrica de Kulik Número normal (el número de ciclos más simples en un diagrama de programa normal);
Métrica de Hura Número ciclomático de una red de Petri que refleja la estructura de control del programa;
Métricas de Whitworth, Zulevsky Una medida de la complejidad del flujo de control. Una medida de la complejidad de un flujo de datos;
Métrica de Peterson Número de ciclos de múltiples entradas;
Métricas de Harrison, Majel Número funcional (la suma de las complejidades reducidas de todos los vértices del gráfico de control); Relación funcional (la relación entre el número de vértices del gráfico y el número funcional); Expresiones regulares (el número de operandos, operadores y paréntesis en la expresión regular del gráfico de control del programa);	f * = norte 1 / f 1
Métrica de Pivovarsky Medida de complejidad ciclomática modificada;	N(G) = * (G) + P yo
Métrica de Pratt Medida de prueba;
Cantón métrico Números característicos de polinomios que describen el gráfico de control del programa;
Métrica de McClure Una medida de complejidad basada en la cantidad de rutas posibles de ejecución del programa, la cantidad de estructuras de control y variables;	C(V) = D(V)J(V)/N
Métrica de Kafur Una medida basada en el concepto de flujos de información;
Métrica de Schutts, Mohanty Medidas de entropía;
Métrica de colofelo Una medida de la estabilidad lógica de los programas;
Métrica de Zolnovsky, Simmons y Thayer Suma ponderada de varios indicadores: - (estructura, interacción, volumen, datos); - (complejidad de la interfaz, complejidad computacional, complejidad de entrada/salida, legibilidad);
Métrica de Berlinger Medida de información;	Yo(R) = (F * (R) F - (R)) 2
Métrica de Schumann Complejidad desde el punto de vista de la teoría estadística del lenguaje;
Métrica más joven Complejidad lógica teniendo en cuenta el historial de cálculos; Complejidad del diseño Saturación de comentarios Número de llamadas externas Número de operadores	C c = log 2 (i + 1)[ n Cxy (n)]
PREVISIÓN DEL MODELO
Modelos Halstead Previsión de recursos del sistema; Previsión del número de errores. modelo IBM Modelo de complejidad total Modelos de conectividad modelo spline	P=3/8 (R a – 1) 2 Ra B = Nlog 2 n / 3000 B = 23M 1 + M 1 0 B = 21,1 + 0,1 V + COMP (S) P ij = 0,15 (S i + S j) + 0,7 C ij P ij = Si (Z ij 2 + N ij 2) ln (Z ij 2 + N ij 2) + + Z i + N 1
MODELOS DE ESTIMACIÓN
Jelinski – Moranda	R(t) = mi - (T – 1 + 1) t
Weiss-Bayes	R 1 (t) = e - - (i –1))t (, /t 1 ,…,t i-1)dd
Chic-Wolverton	R 1 (t) = mi - (norte – 1 + 1) t yo 2 / 2
Poca madera	R 1 (t) = (+ / ++ t) (norte – i + 1)
nelson	Rj(t) = exp(ln(1 – Pj))
Khaletsky	R j (t) = P- (1- nj) / n j
Modelo de depuración	R j (t) =P- f j (,)
modelo mosaico	R j (t) = 1 - (- j - 1)

La tabla presenta varias métricas de complejidad del software para diversas formas de su representación, modelos que predicen el progreso de los procesos de desarrollo de software y modelos probabilísticos para evaluar la confiabilidad.

Echemos un vistazo rápido a las métricas de complejidad. Uno de los principales objetivos del soporte científico y técnico es reducir la complejidad del software. Esto es lo que permite reducir la complejidad del diseño, desarrollo, prueba y mantenimiento, y garantizar la simplicidad y confiabilidad del software producido. La reducción dirigida de la complejidad del software es un procedimiento de varios pasos y requiere un estudio preliminar de los indicadores de complejidad existentes, su clasificación y correlación con los tipos de programas y su ubicación en el ciclo de vida.

La teoría de la complejidad del programa se centra en la gestión de la calidad del software y el control de su complejidad estándar durante la operación. Actualmente, la variedad de indicadores (que en un grado u otro describen la complejidad de los programas) es tan grande que su uso requiere un pedido preliminar. En algunos casos, se satisfacen tres categorías de métricas de complejidad. La primera categoría se define como una métrica de diccionario basada en las relaciones métricas de Halstead, las medidas ciclomáticas de McCabe y las medidas de Thayer. La segunda categoría se centra en las métricas de comunicación que reflejan la complejidad de las relaciones entre los componentes del sistema: estas son las métricas de Win y Winchester. La tercera categoría incluye métricas semánticas relacionadas con el diseño arquitectónico de programas y su diseño.

Según otra clasificación, los indicadores de complejidad se dividen en dos grupos: complejidad de diseño y complejidad operativa. La complejidad del diseño, que está determinada por el tamaño del programa, el número de variables procesadas, la intensidad de la mano de obra y la duración del desarrollo, entre otros factores, se analiza sobre la base de tres componentes básicos: la complejidad de la estructura del programa. , la complejidad de las transformaciones (algoritmos) y la complejidad de los datos. El segundo grupo de indicadores incluye tiempo, programa y complejidad de la información que caracterizan las cualidades operativas del software.

Existen otros enfoques para la clasificación de las medidas de complejidad; sin embargo, si bien capturan los aspectos particulares de los programas en estudio, no permiten (aunque con un gran supuesto) reflejar general, algo cuyas medidas pueden servir de base para las decisiones de producción.

Una característica común inherente invariablemente a cualquier software (y asociada con su corrección) es su ESTRUCTURA. Es importante conectar esta circunstancia con un cierto valor de complejidad estructural en el conjunto de medidas de complejidad del software. Y además, a la hora de analizar la complejidad estructural, conviene limitarnos únicamente a sus medidas topológicas, es decir, medidas basadas en las características topológicas del modelo gráfico del programa. Estas medidas satisfacen la inmensa mayoría de los requisitos de los indicadores: aplicabilidad general, adecuación de la propiedad considerada, importancia de la evaluación, coherencia, expresión cuantitativa, reproducibilidad de las mediciones, baja complejidad computacional, capacidad de automatizar la evaluación.

Son las medidas topológicas de complejidad las que se utilizan con mayor frecuencia en la fase de investigación las que forman las decisiones de gestión de la producción (en los procesos de diseño, desarrollo y prueba) y constituyen un estándar accesible y sensible del producto terminado, que debe ser monitoreado periódicamente durante su operación.

La primera medida de complejidad topológica es la medida ciclomática de McCabe. Se basa en la idea de estimar la complejidad del software por el número de rutas básicas en su gráfico de control, es decir tales caminos, al componerlos se pueden obtener todos los caminos posibles desde la entrada del gráfico hasta las salidas. El número ciclomático (G) de un dígrafo G con n-vértices, m-arcos y p-componentes conectados es la cantidad (G) = m – n + p.

Existe el teorema de que el número de caminos básicos en un dígrafo es igual a su número ciclomático aumentado en uno. En este caso, la complejidad ciclomática de un software P con un gráfico de control G se denomina valor (G) = (G) +1 = m – n + 2. En la práctica, la complejidad ciclomática de un software es igual al número de predicados más uno, lo que permite calcularlo sin construir un gráfico de control simplemente contando los predicados. Esta medida refleja la complejidad "psicológica" del software.

Las ventajas de la medida incluyen la simplicidad de su cálculo y la repetibilidad del resultado, así como la claridad y significado de la interpretación. Las desventajas incluyen: insensibilidad al tamaño del software, insensibilidad a los cambios en la estructura del software, falta de correlación con la estructura del software, falta de distinción entre las construcciones Fork y Loop, falta de sensibilidad al anidamiento de bucles. Las deficiencias de la medida ciclomática llevaron al surgimiento de sus modificaciones, así como a medidas de complejidad fundamentalmente diferentes.

J. Myers propuso el intervalo [1 2] como medida de complejidad, donde 1 es una medida ciclomática y 2 es el número de condiciones individuales más uno. En este caso, el operador DO se considera como una condición y el CASO con n - resultados para n - 1 condiciones. La medida introducida se denominó medida de intervalo.

A W. Hansen se le ocurrió la idea de tomar un par (número ciclomático, número de operadores) como medida de la complejidad del software. Se conoce una medida topológica Z(G) que es sensible a la estructuración del software. Además, es Z(G) = V(G) (igual a la complejidad ciclomática) para programas estructurados y Z(G) V(G) para programas no estructurados. Las variantes de la medida de complejidad ciclomática también incluyen la medida M(G) = (V(G),C,Q), donde C es el número de condiciones necesarias para cubrir el gráfico de control con un número mínimo de rutas, y Q es la Grado de conectividad de la estructura gráfica del programa y su longitud.

Las medidas de complejidad que tienen en cuenta el anidamiento de las estructuras de control incluyen la medida de prueba M y la medida de Harrison-Magel, que tienen en cuenta el nivel de anidamiento y la longitud del software, la medida de Pivovarsky (complejidad ciclomática y profundidad del anidamiento) y McClure. medida: la complejidad del esquema de partición del software en módulos teniendo en cuenta el anidamiento de módulos y su complejidad interna.

La medida funcional de complejidad de Harrison-Majel implica asignar a cada vértice del gráfico su propia complejidad (primaria) y dividir el gráfico en "esferas de influencia" de vértices de predicados. La complejidad de una esfera se llama reducida y se compone de las complejidades primarias de los vértices incluidos en su esfera de influencia, más la complejidad primaria del propio vértice del predicado. Las dificultades primarias se calculan de todas las formas posibles. Por tanto, la medida funcional de la complejidad del software es la suma de las complejidades reducidas de todos los vértices del gráfico de control.

La medida de Pivovarsky pretende tener en cuenta, al evaluar la complejidad del software, las diferencias no sólo entre estructuras de control secuenciales y anidadas, sino también entre programas estructurados y no estructurados. Se expresa mediante la relación N(G) = * (G) + P i , donde * (G) es la complejidad ciclomática modificada, calculada de la misma manera que V(G), pero con una diferencia: un operador CASE con Las n salidas se consideran un operador lógico, en lugar de n – 1 operadores. P i – profundidad de anidamiento de i – ese vértice del predicado.

Para calcular la profundidad de anidamiento de los vértices de los predicados, se utiliza el número de "esferas de influencia". La profundidad de anidamiento se entiende como el número de todas las "esferas de influencia" de predicados que están completamente contenidas en la esfera del vértice en cuestión o se cruzan con él. La profundidad del anidamiento aumenta debido al anidamiento no de los predicados en sí, sino de las “esferas de influencia”. Un análisis comparativo de las medidas ciclomáticas y funcionales del programa discutido para una docena de gráficos de control diferentes muestra que, mientras que otras medidas de esta clase son insensibles, la medida de Pivovarsky aumenta al pasar de programas secuenciales a programas anidados y luego a programas no estructurados.

La medida McClure está diseñada para controlar la complejidad de programas estructurados durante el proceso de diseño. Se aplica a esquemas jerárquicos para dividir programas en módulos, lo que le permite seleccionar un esquema de partición con menos complejidad mucho antes de escribir el programa. La métrica es la dependencia de la complejidad del programa del número de rutas de ejecución posibles, el número de estructuras de control y el número de variables (de las que depende la elección de la ruta). El método McClure para calcular la complejidad está claramente dirigido a programas bien estructurados.

Una medida de prueba M es una medida de complejidad que satisface las siguientes condiciones:

1. La medida de complejidad de un operador simple es 1;

2. M ((F1; F2; …;Fn)) = en M(Fi);

3. M (SI P ENTONCES F1 OTRO F2) = 2 MAX (M (F1), M (F2));

4. M (MIENTRAS P DO F) = 2 M(F).

La medida aumenta con la profundidad del anidamiento y tiene en cuenta la duración del programa. Estrechamente relacionada con la medida de prueba está una medida basada en incrustaciones regulares. La idea de esta medida de complejidad del programa es contar el número total de caracteres (operandos, operadores, paréntesis) en una expresión regular con el número mínimo requerido de paréntesis que describen el gráfico de control del programa. Todas las medidas de este grupo son sensibles al anidamiento de las estructuras de control y a la duración del programa. Sin embargo, el nivel de complejidad computacional aumenta.

Consideremos medidas de complejidad que tengan en cuenta la naturaleza de la ramificación. La medida nodal de Woodward y Hedley se basa en la idea de calcular las características topológicas del flujo de control. En este caso, la complejidad nodal se refiere al número de nodos de transmisión de control. Esta medida rastrea la complejidad de la linealización del programa y es sensible a la estructuración (la complejidad disminuye). Es aplicable para comparar programas equivalentes, preferible a la medida de Halstead, pero en términos de generalidad es inferior a la medida de McCabe.

La medida topológica de Chen expresa la complejidad de un programa mediante el número de intersecciones de límites entre áreas formadas por el diagrama de flujo del programa. Este enfoque es aplicable sólo a programas estructurados que sólo permiten la conexión secuencial de estructuras de control. Para los programas no estructurados, la medida Chen depende significativamente de ramas condicionales e incondicionales. En este caso, puede especificar los límites superior e inferior de la medida. El superior es m+1, donde m es el número de operadores lógicos cuando están anidados. La inferior es igual a 2. Cuando el gráfico de control de un programa tiene un solo componente conectado, la medida de Chen coincide con la medida ciclomática de McCabe.

Las métricas de Gilb evalúan la complejidad de los módulos de programa orientados a gráficos mediante la relación entre el número de transiciones basadas en la condición y el número total de declaraciones ejecutables. La métrica que relaciona el número de conexiones intermodulares con el número total de módulos ha demostrado su eficacia. Estas métricas se utilizaron para estimar la complejidad de circuitos de programas equivalentes, especialmente circuitos de Yanov.

También se utilizan medidas de complejidad que tienen en cuenta el historial de cálculos, la naturaleza de la interacción de los módulos y medidas complejas.

Un conjunto de medidas ciclomáticas es adecuado para evaluar la complejidad de las especificaciones primarias formalizadas, que en conjunto definen los datos iniciales, los objetivos y las condiciones para construir el software requerido. Evaluar este programa “primario” o comparar varias opciones alternativas le permitirá armonizar inicialmente el proceso de desarrollo de software y, desde el punto de partida, controlar y gestionar su complejidad actual resultante.