Yuzi download: reporting

Showing posts with label reporting. Show all posts

Wednesday, October 26, 2016

Google Play Developer Console introduces Universal App Campaigns and User Acquisition performance reporting

Posted by Frederic Mayot, Google Play team

At Google I/O in May, we previewed some new and powerful tools to help you further grow your business and improve decision making based on smarter insights on Google Play. We are happy to announce that, today, these features are live in the Developer Console.

User Acquisition: AdWords Campaigns

With just a few simple steps, universal app campaigns lets you easily set up ad campaigns from within the Google Play Developer Console and promote your app across Google Play, Google Search, YouTube and the Google Display Network. You will now be able to more effectively find and grow your install base with the help of Google’s unparalleled reach.

App install ads generated from one universal app campaign

Universal app campaigns automatically pull in images, video, and descriptions from your Google Play store listing to generate ad formats that look great wherever they are placed. From there, our systems automatically optimize your campaigns and experiment with different creatives and bids to maximize app install volume as close as possible to your target cost-per-install.

"With universal app campaigns, we only had to set up one campaign that drove more than 10,000 new installs in one month and install volume is continuing to trend up over time. Were also seeing a 20% lower CPI compared to other channels." – José Maria Pertusa, CMO of Linio

To get started with your first campaign, select the User Acquisition tab for your app in the Developer Console and choose ‘AdWords Campaigns.’

User Acquisition: Performance report

When you’re growing an audience for your app, you’ll want to understand where your most valuable users are coming from. The new performance report on the User Acquisition tab in the Developer Console lets you see how people are finding your Play Store listing, how many install your app, and how many go on to make purchases.

The performance report also tracks marketing links tagged with UTM tags, so you’ll be able to get more granular detail on how well your promotion is doing. Once you’ve got visitors to your Play Store listing, you’ll want to start thinking of ways to increase the number of visitors turning into installers. The new Store Listing Experiments feature can help you run A/B tests to do just that.

How to get started in the Developer Console

To learn how to take advantage of these new features in the Developer Console, watch the DevByte video below in which I explain how to set up your first universal app campaign and how to view the new data offered on the performance tab.

We hope you’ll use these user acquisition tools to grow a valuable audience for your app or game. We continue to improve our features for developers based on your feedback – like the recent improvements to beta testing and Store Listing Experiments – in order to help you grow your app or game business globally on Google Play.

Available link for download

DMARC Domain based Message Authentication Reporting Conformance

Cuando se recibe un correo electrónico que no viene firmado digitalmente, siempre es complicado para el destinatario saber si es auténtico o no. Si todos los mensajes llegaran firmados con PGP o S/MIME y las herramientas que utilizamos habitualmente fueran sencillas a la hora de utilizar estas tecnologías no habría que buscar otras alternativas. Por desgracia esto no es así y se han buscado soluciones como SPF (Sender Policy Framework) / SenderID o DKIM (DomainKeys Identified Mail) para paliar esta solución. Pero la situación es aún un poco confusa ya que las configuraciones que hacen muchos dominios de ellos no son correctas y las limitaciones que tienen las tecnologías SPF/SenderID o DKIM hacen que los proveedores de correo electrónico no se atrevan a confiar ciegamente en ellos.

Figura 1: DMARC - Domain-based Message Authentication, Reporting & Conformance

Esta situación ha llevado a que grandes proveedores como Gmail han llegado a obviar completamente SPF o que la firma DKIM de un mensaje de correo electrónico no genere ninguna alerta positiva de verificación en Hotmail, a diferencia de lo que ocurre, por ejemplo, en Gmail con las cuentas de Ebay o Paypal.

Figura 2: Icono de llave en mensajes de Ebay firmados con DKIM

Viendo este ecosistema hacía falta una solución de análisis de los mensajes de correo electrónico que verifique todos los patrones para poder determinar si un mensaje es correcto o no, evaluando las firmas SPF/SenderID y DKIM y tomando una decisión en función de las configuraciones globales. Nosotros en Informática64, tiempo atrás, creamos un plugin para el navegador que hacía estas verificaciones y lo llamamos el Proyecto Apolo. Con él, analizando SPF y la configuración del dominio que lo enviaba, mostrábamos un icono al lado de cada mensaje de correo electrónico en Gmail.

Figura 3: El plugin del Proyecto Apolo mostraba información con las validaciones SPF

En aquel proyecto nosotros no analizábamos DKIM y basábamos todo nuestro trabajo en las configuraciones de SPF y SenderID. Con esta misma idea, hace ya unos años se comenzó a trabajar en un estándar que siguiera las mismas ideas que nuestro proyecto Apolo, pero usando ahora SPF/SenderID y DKIM en la lógica de la validación. Este estándar se llama DMARC: "Domain-Based Message Authentication, Reporting & Conformance" y tiene, además de la validación, la posibilidad de establecer un sistema de reporte para enviar información de los correos que están incumpliendo las políticas y una forma de forzar que las políticas se cumplan en todos los posibles subdominios de una organización.

DMARC: Domain-based Authentication, Reporting & Conformance

El funcionamiento de este protocolo es el que se ve en la figura siguiente. En él se puede ver en la fila del medio del gráfico que, cuando llega el mensaje al destinatario, el servidor valida la información DKIM, valida la información SPF y después, con estas dos comprobaciones previas, valida la información DMARC para aplicar una de las políticas que se pueden ver en la fila inferior.

Figura 4: Flujo de funcionamiento de DMARC

Por último, si un mensaje de correo electrónico cumple todas las validaciones correctamente, es decir, viene firmado por DKIM correctamente con una clave de firma que está en el DNS de la organización y pasa la comprobación SPF al ser enviado desde una de las direcciones IP marcadas en el registro SPF como una de las autorizadas, entonces el proveedor podrá tener las máximas garantías de legitimidad del mensaje posibles - que aún así siempre inferiores a que el mensaje venga firmado digitalmente con una clave de remitente -.

En el caso de Hotmail u Outlook.com, los mensajes de algunas grandes compañías que han implantado DMARC y cumplen DKIM y SPF correctamente, reciben un escudo verde en el cliente web, similar a la llave que pone Gmail a los mensajes de Ebay o Paypal que vienen firmados por DKIM. En el caso de DMARC, las verificaciones son SPF y DKIM, por lo que son mucho más estrictas.

Figura 5: mensajes en Outlook.com de Apple

En la imagen podéis ver cuatro mensajes de correo electrónico provenientes de Apple.com. Los cuatro pasan la política SPF y los cuatro vienen firmados correctamente por DKIM, pero Hotmail/Outlook.com ha puesto el escudo verde solo en uno de ellos porque es lo que han decidido hacer por acuerdo, no porque unos tengan más medidas de seguridad que otros.

Verificando un política DMARC

Vamos a ver con el cuarto mensaje cómo se comprueban todas las comprobaciones con DMARC para que al final Outlook.com ponga el escudo verde al mensaje de correo. Si miramos el código fuente del mensaje, podemos ver que el dominio del remitente es id.apple.com. Este es el dominio que se ha elegido para verificar los mensajes de correo electrónico que lleguen y ponerle el escudo verde. Todos los mensajes que lleguen de ese dominio serán validados por DMARC a ver si son merecedores del escudo verde o no.

a) Paso 1: Verificación SPF

Primero tenemos que comprobar el registro SPF en el servidor DNS para ver qué direcciones IP son las autorizadas por id.apple.com para enviar mensajes de correo electrónico con su dominio. Como se puede ver la lista está compuesta por 6 segmentos de direcciones IP. Además, la política que se ha elegido para el protocolo de Sender Policy Framework - ya que es un registro spfv1 - es de softfail.

Figura 6: Configuración SPF de id.apple.com

Si miramos el código fuente del mensaje de correo electrónico podemos observar que ha sido entregado desde un servidor con la dirección 17.151.1.33, que pertenece a uno de los rangos marcados en el registro SPF.

Figura 7: Verificación de SPF en el correo electrónico recibido

Por tanto, como se marca en el código fuente del mensaje, aparece como que el correo electrónico ha pasado correctamente la validación SPF.

b) Paso 2: Verificación DKIM

Si miramos el código fuente de mensaje enviado desde id.apple.com, podemos ver cómo viene firmado digitalmente por el servidor que envía el mensaje usando una clave llamada id2048 que el servidor de correo entrante debe poder obtener en el servidor DNS de id.apple.com.

Figura 8: Firma DKIM del mensaje de id.apple.com

Si nos conectamos al servidor DNS de id.apple.com y buscamos el registro que debe contener la clave, es decir, id2048._domainkeys.apple.com, podemos ver cuál es el valor de la parte pública de esta clave.

Figura 9: Clave pública id2048 en el DNS de id.apple.com

Además, la política DKIM para Apple.com está configurada con un softfail (o=~) también. En este caso, aún la mantiene en modo test (t=y).

Figura 10: política DKIM de Apple.com

Para este correo en concreto no hay ningún problema porque el servidor de correo electrónico entrante, es decir, Outlook.com, se ha conectado al servidor DNS, ha recogido la clave pública de id2048 y ha verificado que el mensaje de correo electrónico está correctamente firmado.

c) Paso 3: Política DMARC

Llegados a este punto, debemos revisar la política DMARC de id.apple.com. Esta se encuentra en el registro DNS llamado _dmarc.id.apple.com y tiene una configuración bastante sencilla en la que indica cuáles son las direcciones de correo electrónico a las que se debe enviar información de los correos que no cumplan las políticas SPF y DKIM anteriores.

Figura 11: Configuración del registro DMARC de id.apple.com

La configuración del registro DMARC en el servidor DNS se hace con un registro TXT en el que hay que configurar una serie de valores. En primer lugar la versión, que a día de hoy es DMARC1, luego las direcciones de e-mail en las que se quiere reportar aquellos mensajes que incumplan las políticas para hacer un análisis forense y en las que se van a enviar los reportes agregados con estadísticas.

Figura 12: Valores de configuración de registro DMARC

Luego, se configuran valores como la política a aplicar, que en el caso de id.apple.com es la de rechazar cualquier correo electrónico que no cumpla con la política SPF y la política DKIM.

Políticas para subdominos y alineamiento con DKIM & SPF

Una de las cosas interesantes del protocolo DMARC es que tiene en cuenta los ataques que realizan los suplantadores de identidad inventando subdominios con sp. En este caso, muchos servidores de correo electrónico no verifican que los registros SPF de los dominios padres prohiben el envío de mensajes desde una determinada dirección IP y buscan ser entregados al buzón de la víctima como si el subdominio no tuviera configurado el registro SPF. Además, tiene configuraciones para que la política que se aplique sea la configurada en DKIM o SPF, con los valores de alineamiento (adkim & aspf).

DMARC es un paso más para intentar evitar la suplantación de direcciones de remitente en mensajes de correo electrónico que, si es posible, merece la pena que configures en tu organización.

Saludos Malignos!

Available link for download

Wednesday, October 26, 2016

Google Play Developer Console introduces Universal App Campaigns and User Acquisition performance reporting

Google Play Developer Console introduces Universal App Campaigns and User Acquisition performance reporting

Wednesday, October 5, 2016

DMARC Domain based Message Authentication Reporting Conformance

DMARC Domain based Message Authentication Reporting Conformance