Envio de datos en formato batch al DMP via SFTP (DATA‑IN)

Nota: Previo a enviar datos de usuarios web al repositorio SFTP deben existir una sincronización de usuarios.

En este documento trataremos cómo realizar una integración de envío de datos mediante SFTP para que el cliente enriquezca la información de sus usuarios dentro de la plataforma DMP. La misma consta de los siguientes pasos:

• 1. Configuración del repositorio SFTP
• 2. Generación de archivos con un formato específico
• 3. Envío de los archivos en baches al repositorio SFTP
• 4. Obtención del estado de cada archivo subido
• 5. Generación de taxonomía

1. Configuración del repositorio SFTP

El cliente debe configurar un repositorio SFTP desde donde Retargetly leerá los archivos con los datos de usuarios. También debe asegurarse que este repositorio tenga el espacio necesario para alojar todos los archivos que se suban periódicamente, y los mismos deben perdurar con un mínimo de 30 días desde la fecha de creación. Esto es para asegurarnos que ante cualquier fallo el sistema tenga posibilidad de volver a extraer los mismos y no haya pérdida de información.

Retargetly enviará la siguiente información para que el cliente pueda crear el repositorio SFTP:

retargetly.pub ‑> [Archivo con la clave pública de acceso SFTP]

Esta clave pública debe ser instalada para el acceso al SFTP mediante el usuario "retargetly".

Retargetly deberá recibir la siguiente información (solo los campos cuyo valor está entre

• Protocolo: SFTP
• Usuario: retargetly
• Host: [dirección del host]
• Puerto: [numero del puerto]

1. Generación de archivos con un formato específico

El cliente deberá generar archivos periódicamente y publicarlos dentro del SFTP. Los archivos necesitan tener un formato estándar para que el sistema pueda leerlos correctamente.

Nombre de archivo

Cada archivo generado debe estar dentro de un directorio que sigue las siguientes características:

[YYYYMMDD]/[archivo.tsv.gz]

Consideraciones:

• El nombre de los archivos debe terminar con ".tsv.gz" y luego cualquier cadena de caracteres que desee el cliente.
• La fecha por la cual se completa el directorio /YYYYMMDD debe ser la fecha en la cual fueron creados los archivos y subidos, incluso si en esa misma carpeta hay archivos de diferentes días.
• Los archivos deben ser TSV válidos y estar comprimidos en formato GZIP, por eso la extensión al final es "tsv.gz".

Ejemplos válidos:

• 20181021/custom_name_0000.tsv.gz
• 20181021/custom_name_0001.tsv.gz
• 20181021/another_file.tsv.gz

Ejemplo de directorios y nombres inválidos:

• 21/rely_custom_name_0000.tsv.gz ‑> incorrecto directorio inicial
• 2018/10/21/rely_custom_name_0000.tsv ‑> incorrecta extensión de archivo y directorio
• 2018_10_21/rely_custom_name_0000.tsv.gz ‑> incorrecto directorio inicial

Formato de archivo

El contenido de cada archivo debe siempre seguir un patrón definido:

[tipo de dispositivo][TAB][ID usuario][TAB][atributos separados por coma][Caracter de fin de línea (\n)]

Valores posibles del tipo de dispositivo:

• web (indica que son web cookies)
• android (indica que son dispositivos android)
• ios (indica que son dispositivos ios)
• ml_raw (e‑mail del usuario)
• ml_sh2 (e‑mail del usuario en formato sha256)
• ml_sh5 (e‑mail del usuario en formato sha512)
• mb_raw (celular del usuario)
• mb_sh2 (celular del usuario en formato sha256)
• mb_sh5 (celular del usuario en formato sha512)
• nid_raw (identificador nacional del usuario)
• nid_sh2 (identificador nacional del usuario en formato sha256)
• nid_sh5 (identificador nacional del usuario en formato sha512)

Ejemplos válidos:

• ml_raw ejemplo@gmail.com propiedad1,propiedad2,propiedad3
• ml_sh2 fc2ae4a1fb374548ea80556dc51ab3471a311231d8bffaa1dece31371bcceb62 propiedad2,propiedad3,propiedad4
• ml_sh2 bea1debd1d52608ac7c0723aed5bd4ce3e821cffdde924bd760a64f40e550313 1b671a64‑40d5‑491e‑99b0‑da01ff1f3341 propiedad6,propiedad7,propiedad8

Aclaración: entre el tipo de dispositivo, el ID usuario y los atributos hay un caracter TAB, también referenciado como \t. Además al final de cada línea está el caracter de fin de línea, también referenciado como enter o \n. No es válido el caracter retorno de carro, también referenciado como \r.

Aclaración 2: si se envían atributos e‑mail, número celular o identificador nacional en formato sha256 o sha512, los mismos deberán ser formateados previo a aplicar el algoritmo de hasheo de esta forma.

E‑mails: todo en minúscula. Ejemplo: ejemplo@gmail.com

Identificador nacional: solo números, se debe borrar cualquier otro caracter. Ejemplo: 34848988

Número celular: solo números y en el formato (código de país)(código de área sin 0) (número). Ejemplo: 541151190123

Ejemplos inválidos:

• ml_raw,ejemplo@gmail.com,propiedad1,propiedad2,propiedad3 ‑> el caracter que divide el ID de cliente de los atributos no es TAB
• propiedad1,propiedad2,propiedad3 ejemplo@gmail.com ml_raw ‑> incorrecto orden de los datos
• ejemplo@gmail.com ‑> no hay tipo de dispositivo ni atributos cargados para este usuario

1. Envío de los archivos en baches al repositorio SFTP:

Para la generación de archivos, luego de tener definidos los formatos de los mismos, el proceso tiene que cumplir con las siguientes políticas:

• No hay límite de paso para los archivos a cargarse.
• Los archivos deben durar como mínimo 30 días luego de la fecha de generación.
• Luego se pueden borrar.

1. Obtención del estado de cada archivo subido:

Por cada archivo generado dentro del SFTP se puede obtener el estado del mismo. Los archivos tienen 3 estados posibles:

• En proceso
• Fallado
• Exitoso

Estos 3 estados se informan como un archivo hermano del archivo a ingestar, pero con las siguientes extensiones:

• processing ‑> archivo sin contenido
• failed ‑> archivo con un mensaje de error
• success ‑> archivo con los resultados del procesamiento

Ejemplo, si el sistema está procesando el archivo /20181021/custom_name_0000.tsv.gz

En la misma carpeta, estará presente este archivo:

• 20181021/custom_name_0000.tsv.gz.processing

Y una vez finalizado, el .processing se eliminará y se creará este archivo en caso de haber sido exitosa la ejecución:

• 20181021/custom_name_0000.tsv.gz.success

1. Generación de Taxonomía

El cliente debe enviar al soporte de Retargetly una lista de propiedades que se recibirán para los usuarios. De esta forma Retargetly le devolverá el mismo listado pero adjuntando los ID de Segmentos correspondientes dentro de la plataforma DMP.

Es todo, esperamos que haya sido útil!!