Guía de implementación Digital Analytix

De Gobmx
Saltar a: navegación, buscar

Paso 1 Inserción de Tag DAx Full-Standard

(En todas las páginas dentro del sitio de las dependencias).

Debes descargar e insertar el TAG Digital Analytix.txt lo más cercano a la apertura de la etiqueta <body>.

Tag Digital Analytix.txt

Form.js

Los valores del parámetro “name” son los únicos que deben de cambiar correspondiendo a la sección, subsección o detalle/nota dentro del sitio y que haga referencia clara a la estructura y el contenido consumido.


Digital1.png

Nota Importante

  • Los valores de la etiqueta “name” son los únicos que deben variar según la página donde el tag se ejecuta y que se basa en la estructura del sitio.


Sintaxis

https://sb.scorecardresearch.com/p?c1=2&c2=17183199&ns_site=gobmx&name=area.seccion


Dentro del tag de Digital Analytix se encuentran los siguientes parámetros:


c2 Identificador de la cuenta de gob.mx hacia comScore, para esta implementación siempre debe ser c2=17183199


ns_site Parámetro que contiene el nombre identificador del sitio, el cual valida que el tráfico recibido en nuestra plataforma sea contabilizado dentro de la cuenta. Para esta implementación siempre debe ser ns_site=gobmx


name Cadena de caracteres que contiene la estructura en secciones, la cual identificará el contenido de páginas dentro de Digital Analytix. Para una buena medición este parámetro debe ser llenado correctamente para cumplir con los reportes propuestos en el modelo de medición. En algunos casos una forma de realizar el llenado del parámetro es guiándose en la URL (cuando esta, es amigable y cumple la estructura sección.subseccion.detalle. )

Otra opción es usar la estructura de breadcrumbs de navegación en el sitio.


Para el parámetro name, el separador entre sección, subsección y detalle es el signo punto.

Adicionalmente para la creación de estos valores es necesario validar caracteres como acentos caracteres especiales y espacios (deben sustituirse por – o _) sustituyéndolos tomando en cuenta la tabla siguiente:


Digital2.png

Notas Importantes

  • Al menos deben existir dos niveles en el name, por ejemplo, para una portada de sección principal, se recomienda un nombramiento como name=inicio.portada
  • Al ser muchas las dependencias que sumarán tráfico al mismo lugar, se recomienda anteponer siempre en el parámetro name siglas que identifiquen una dependencia de otra.
    • Entonces, bajo esta recomendación el name podría ser por ejemplo:
      • name=sct.inicio.portada (haciendo referencia a Secretaria de Comunicaciones y Transportes)
      • name=sre.saladeprensa.portada (haciendo referencia a la Secretaria de Relaciones Exteriores)

Librería JS Digital Analytix

Esta línea de código (incluida en el archivo Tag Digital Analytix.), realiza la llamada a la librería JS de Digital Analytix, esta debe estar presente siempre en cada página donde se encuentra el tag. Preferentemente debe incluirse antes del cierre de la etiqueta </body>


Digital3.png


Solo en las secciones de los sitios que se encuentren en un ambiente o modo seguro SSL, deberá realizarse la llamada de la librería y nuestro tag con la siguiente sintaxis:


Digital4.png

Validación

Al finalizar la implementación, es necesario confirmar al equipo de comScore (customersupport@comscore.com con copia a ventanillaunica@ugd.gob.mx) con el asunto en el mensaje, “revisión de sitio dependencia e indicar la URL” para realizar una validación en este punto del proceso y así asegurar la medición correcta y recomendada y después seguir al siguiente paso.

Paso 2 Medición del buscador interno

Para medir términos de búsqueda y resultados en buscadores internos, se deben adicionar dos parámetros o etiquetas al Tag Digital Analytix previamente implementado (Paso 1) únicamente en la página donde se desplieguen los resultados de búsqueda:

Las etiquetas/parámetros a utilizar son:

ns_search_term Este parámetro debe contener el término de búsqueda utilizado por el usuario.

ns_search_result Este parámetro debe contener el número de resultados encontrados para la búsqueda específica.

Ejemplo Práctico:

En el sitio de gob.mx se realiza una búsqueda sobre “Informe de Gobierno” dentro del buscador interno del sitio. Esta busqueda devuelve 1,692 resultados que coinciden con este termino de búsqueda.


Digital5.png


Entonces, para este ejemplo, las etiquetas especificadas se deben llenar:

ns_search_term=Informe de Gobierno ns_search_result=1692

Y la cadena de medición se deben agregar de la siguiente forma:

https://sb.scorecardresearch.com/b?c1=2&c2=17183199&ns_site=gobmx&name=resultado_busqueda.resultado&ns_search_term=Informe%20de%20Gobierno&ns_search_result=1692

Notas Importantes

  • Las etiquetas de búsqueda deben estar presentes únicamente si se realizó una búsqueda en el sitio y deben contener siempre algún valor (no pueden estar vacías).
  • Se recomienda que el parámetro name de la página de resultados siempre sea igual, ejemplo name=resultados_busqueda.resultado


Validación

Al finalizar la implementación, es necesario confirmar al equipo de comScore (customersupport@comscore.com con copia a ventanillaunica@ugd.gob.mx) con el asunto en el mensaje, “revisión de sitio dependencia e indicar la URL” para realizar una validación en este punto del proceso y así asegurar la medición correcta y recomendada y después seguir al siguiente paso.

Paso 3 Medición de Interacciones

(Clicks en descargas de documentos, intención de usuarios para comentar contenidos, compartir, clicks en botones “de acuerdo” o “en desacuerdo”, etc.)

La función JS uid_call(a,b) que se encuentra en el Tag Digital Analytix (implementado en el Paso 1), tiene como finalidad medir interacciones que los usuarios tienen con el sitio, para cumplir con el modelo de medición se debe medir, la intención de descargas de documentos, sistemas de votación como “de acuerdo/desacuerdo con el documento”, intención de compartir contenidos, flagging, descargas de algún archivo, realizar un trámite, etc.

Esta función debe llamarse al ejecutar la acción de dicho elemento interactivo, en la mayoría de los casos a través del onClick desde su anchor (pero también puede ser en botones).


Digital6.png

Notas Importantes

  • Es muy importante especificar qué tipo de interacción se está midiendo, por ejemplo si es descarga de un archivo en PDF se deberá diferenciar de un clickout que lleva a una página fuera del sitio o clickin que lleva a otro contenido dentro del sitio.
  • Además debe tener un nombre que pueda ser identificable dependiendo del tipo de tramite/archivo que se trata, por ejemplo:


Digital7.png


En la imagen siguiente se marca con flechas que contenidos deben ser marcados como interacciones, en algunos sitios podría variar pero es importante medir aquellos botones, links, links para descarga disponibles a los usuarios.


Digital8.png


Validación

Al finalizar la implementación, es necesario confirmar al equipo de comScore (customersupport@comscore.com con copia a ventanillaunica@ugd.gob.mx) con el asunto en el mensaje, “revisión de sitio dependencia e indicar la URL” para realizar una validación en este punto del proceso y así asegurar la medición correcta y recomendada y después seguir al siguiente paso.

Paso 4 Medición de actividad de usuarios registrados

(En todas las páginas dentro del sitio en que los usuarios que hicieron login consumen contenido/ interactúan).

En Digital Analytix existe el concepto Custom Label o Etiqueta Personalizada, para poder capturar cualquier tipo de información, dentro del Tag Digital Analytix implementado en los sitios. Para generar una etiqueta simplemente se debe agregar como un parámetro nuevo, como se muestra a continuación:


Digital9.png


Una vez insertada la etiqueta, se le debe asignar algún valor. Entonces si algún trámite o alguna sección del sitio pueden consultarse por medio de logins.

En algunos casos, el login puede ser un ID único asignado, en otros podría ser el RFC o CURP, etc. Entonces ejemplificando la URL de medición deberá armarse como:

https://sb.scorecardresearch.com/b?c1=2&c2=17183199&ns_site=gobmx&name=ejemplo_etiquetas&id_usuario=vivj890314wh3

Notas Importantes

  • Se recomienda una etiqueta fácil de identificar y unificada en cualquier dependencia para usuarios registrados o no, por ejemplo id_usuario y este debe existir siempre en la navegación.
  • Para usuarios no loggeados puede existir con un valor genérico y que se pueda distinguir que no es un usuario loggeado, por ejemplo id_usuario=null
  • Mientras que para usuarios registrados la etiqueta debe existir durante toda su navegación mientras el usuario no cierre su sesión, ejemplo id_usuario=CURP


Validación

Al finalizar la implementación, es necesario confirmar al equipo de comScore (customersupport@comscore.com con copia a ventanillaunica@ugd.gob.mx) con el asunto en el mensaje, “revisión de sitio dependencia e indicar la URL” para realizar una validación en este punto del proceso y así asegurar la medición correcta y recomendada y después seguir al siguiente paso.

Paso 5 Medición de Formularios

Este script fue diseñado para reportar la interacción en formularios web.

Recolección de Datos

Tres eventos de formulario deben ser medidos para esta implementación:

  • Submit (habilitado por default)
  • Abandono
  • Validación de errores

Estos eventos pueden tener información adicional también, por ejemplo valores input que para el modelo de medición, deben ser enviados siempre para cada formulario:

  • INPUT type=text or TEXTAREA
    • El valor puede ser enviado completamente.
  • INPUT type=hidden
    • El valor puede ser enviado completamente.
  • INPUT type=password
    • Yes o NO puede indicar si se completo.
  • INPUT type=radio o SELECT (listas)
    • Valor(es) de texto seleccionados pueden ser enviados.
  • INPUT type=checkbox
    • La selección de cada opción puede ser reportada como YES o NO.

Ejemplo de Formularios y eventos correspondientes adicionales que puede incluir un formulario

Digital10.png


Requerimientos

La base de requerimientos para la implementación de este producto es:

  • Un documento HTML utilizando el Compact Measurement Code
  • Submit de formularios vía INPUT con atributo type y valor submit o image, o también un elemento BUTTON o un LINK contenido dentro de la etiqueta <FORM>
  • Browser reciente con JS habilitado


Checklist

Su checklist antes de iniciar esta implementación debe ser:

  • Inventario de formularios a reportar
  • Inventario de campos a reportar (para esta implementación deben medirse todos)
  • Incluir el <SCRIPT> que deben descargar con el nombre Form.js
  • Asegurarse que se encuentra en uso el Compact Measurement Code
  • Elegir uno de los dos métodos de implementación:
    • Para el método Markup:
      • Establecer la clase class=ns_ en todos los formularios
    • Para el método Code:
      • Escribir el bloque de inicialización
      • Colocar justo debajo del include SCRIPT


Métodos de Implementación

Camino A. por Markup (basada en clases)

Método en el que se utiliza el atributo class para declarar muy detalladamente el reporteo del formulario y los campos del mismo.

Solo agregando class=ns_ a cualquier elemento, habilitará la transmisión de los tres tipos de evento de formulario mencionados.


Proceso

Insertar la definición class=ns_ en todos los campos y formularios a reportar, e incluir el script Form.js. Toda la recolección sucederá después del evento body.load


Ejemplo

<form class=”ns_” action=”response.html” method=”get”>

<input class=”ns_” type=”text” name=”firstname” maxlength=”150” />


(…)


  1. Carga del script

Puede incluir el SCRIPT en cualquier parte del documento con la sintaxis mostrada a continuación. Siempre que esté en el evento page.load, este encontrará sus tags y los inicializará.

Incluir la siguiente instrucción:

<script language=”JavaScript1.2” src=”Form.js”></script>

Nota: los errores de validación son solamente medidos si los notifica llamando el método JS descrito más adelante en este documento.


Camino B. por Code (con funciones JS)

Utilizando el JS API obtienen flexibilidad total de configuración, por lo que pueden adaptar a cualquier escenario de reporteo.

Proceso

Incluir el SCRIPT en el documento con la siguiente instrucción:


<script language=”JavaScript1.2” src=”Form.js”></script>


Y un block de inicialización que es básicamente una línea de código: new ns_.Form(form, settings);

  1. Objeto o ID Form
    • Argumento 1: FORM
    • Primero debe indicar qué Formulario se reportara, ya sea atributo ID o NAME o el objeto JS mismo (se recomienda que sea lo mejor detallado y diferenciado de los demás, posible para un reporteo más sencillo).
    • Para medir todos los formularios, entonces habrá que usar el comodín *
  2. Preferencias de reporteo
    • Argumento 2 CONFIGURACIÓN DE REPORTEO
    • El siguiente argumento definirá que campos se reportaran, junto con qué eventos (que dependiendo el formulario, para esta implementación deben ser todos).

Al igual que el primero, puede utilizar el comodín * para todos los campos de un formulario.

Por temas de privacidad, se ha separado la declaración de campos en:

        • Normal
        • Password
        • Hidden
    • Entonces:

{

“ID_de_campo” : {

submit: true,

abandon: true,

failure: true }

}

TODOS LOS CAMPOS

Tome en cuenta que se puede usar el comodín * para seleccionar todos los campos en un formulario: {

“*” : {

submit: true

}

}

Nota: el comodín no habilita el reporteo de eventos password o hidden.


CAMPOS PASSWORD Y OCULTOS

{

“ID_de_campo_password” : {

password: {

submit: true,

abandon: true,

failure: true}

},

“ID_de_campo_oculto” : {

hidden: {

submit: true

}

}

},


PREFERENCIAS POR DEFAULT

No se envían campos por default. Aunque habilitándolos, solo campos normales se transmitirían y solo en eventos submit events.

Expresado en su sintaxis: {

submit: true,

abandon: true,

failure: true,

password: {

submit: false,

abandon: false,

failure: false

},

hidden: {

submit: false,

abandon: false,

failure: false

}

}

Nota: utilizar el comodín * sobrescribiría las configuraciones por default, convirtiéndose en los predeterminados para subsecuentes declaraciones.

CUSTOM LABELS

Al querer enviar cualquier dato personalizado, se puede hacer pasando un objeto en un 3er argumento, conteniendo una propiedad llamada labels con un valor combinado en pares alfanuméricos name+value.

Ejemplo:

New ns_.Form (“ID_Form”), “*”, {

labels: {

“customlabel1”: “value1”,

“customlabel2”: “value%20with%20spaces”

}

} );


ERRORES DE VALIDACIÓN

Una vez realizadas las pruebas de validación, y basados en los resultados, se podrá notificar cada error llamando el método ns_.Form.onFailure tantas veces como se hayan generado errores. Para cada error, se necesita un llamado como el siguiente: ns_.Form.onFailure(form, field, message);

Dónde: • Form es el objeto formulario, ID o Nombre • Field es el campo erróneo, ID o Nombre • Message descripción del error.


3) Colocar el block de inicialización a. El único requerimiento al colocar el bloque del SCRIPT conteniendo la inicialización de este producto, es que puedan hacer el llamado a la creación ns_.Form una vez que el script externo ha sido cargado en la página. Adicionalmente, si el elemento del formulario no se encuentra en el árbol DOM cuando la inicialización es invocada, el script intentara nuevamente después del evento window.load


Validación

Al finalizar la implementación, es necesario confirmar al equipo de comScore (customersupport@comscore.com con copia a ventanillaunica@ugd.gob.mx) con el asunto en el mensaje, “revisión de sitio dependencia e indicar la URL” para realizar una validación en este punto del proceso y así asegurar la medición correcta y recomendada y después seguir al siguiente paso.

Seguridad

Es importante realizar la llamada de la librería de comscore y el tag utilizando la opción de canal seguro, de esta manera el intercambio de información viaja cifrada. La url a utilizar es la siguiente:

https://sb.scorecardresearch.com/c2/17183199/ct.js

En los trámites a incluir en 2015 es mandatorio el uso de certificado de seguridad para proteger la información que se envía como parte del monitoreo.

Roadmap

Implementación de Digital Analytix

Dogital11.png