Implementar la segmentación a nivel de fila en contenido de Looker insertado

Artículo escrito por Christopher Seymour, analista de datos sénior, y Dean Hicks, ingeniero de relaciones con desarrolladores

La segmentación a nivel de fila le permite limitar los datos a los que puede acceder un usuario concreto en función de los valores almacenados en uno o varios campos de la base de datos. En esta guía se describen los métodos para implementar la segmentación a nivel de fila en el contenido de Looker insertado y se incluyen las siguientes secciones:

Introducción

La función de inserción de Looker es una de las funciones más potentes y valiosas del producto. Si estás leyendo esta guía, es probable que ya estés insertando contenido de Looker en tu aplicación o que tengas previsto hacerlo en un futuro próximo.

El objetivo de esta guía es ayudarte a entender mejor el diseño de la función de inserción de Looker y cómo implementar la segmentación en una aplicación en la que los partners puedan gestionar el acceso a varias marcas. Como se trata de un análisis detallado del tema, es un poco largo, así que ten en cuenta que esta guía no está pensada para solucionar rápidamente un problema sencillo, sino que es un elemento básico para ayudarte a gestionar mejor todo tu caso práctico de inserción de Looker.

Resumen de uso

En esta guía se describe un caso práctico habitual en el que tu empresa inserta contenido de Looker en su producto y ofrece segmentos de usuarios que deberían ver diferentes porciones de tus datos.

En este caso práctico de inserción firmada, supongamos que eres el administrador de tu instancia de Looker. Hay dos tipos de usuarios externos de inserciones: clientes, que solo deberían poder acceder a los datos relacionados con su marca específica, y partners, que podrán acceder a los datos de varias marcas. Tienes un panel de control con varias tarjetas que muestras a todos los clientes que usan tu producto, pero necesitas que el panel se filtre automáticamente para cada cliente de forma que solo se muestren los datos específicos de ese cliente. En los ejemplos de este documento se usan dos empresas ficticias: Hooli y Pied Piper.

Tiene una tabla llamada products, que muestra algunas métricas de producto de diferentes marcas. Cada marca corresponde a un usuario insertado diferente (con un external_user_id diferente) en la aplicación insertada firmada. Como cada usuario insertado solo debería poder ver los datos de su propia marca, tienes una Exploración que usa un filtro de acceso en un atributo de usuario brand:

explore: products {
  access_filter: {
    field: products.brand
    user_attribute: brand
  }
}

Tienes un panel de control basado en esta exploración que tiene dos baldosas: una muestra el nombre de la marca y la otra, el número de productos de esa marca.

Usa el endpoint create_sso_embed_url para generar URLs de inserción de este panel para cada usuario insertado. En este ejemplo se usan dos marcas: Pied Piper y Hooli. Este es el cuerpo de la solicitud que se usa en la llamada create_sso_embed_url de Pied Piper, con external_user_id pied_piper:

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "pied_piper",
  "first_name": "PiedPiper",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Pied Piper"}
}

La URL que has generado para Pied Piper muestra el panel de control de esta forma:

Este es el cuerpo de la solicitud que se usa en la llamada create_sso_embed_url de Hooli, con external_user_id hooli:

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "hooli",
  "first_name": "Hooli",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Hooli"}
}

La URL que se ha generado para Hooli muestra el panel de control de esta forma:

Voilà! El panel de control se filtra según el valor del atributo de usuario marca de cada usuario insertado.

Profundizar

¡Qué guay! ¿Y si quiero dar acceso a un solo usuario a varias marcas? ¿Cómo puedo asegurarme de que solo los usuarios pertinentes vean mis datos?

¡Buenas noticias! La función de inserción firmada de Looker se ha diseñado para que los desarrolladores puedan crear experiencias de datos potentes y personalizadas para los usuarios, al tiempo que se asegura de que se mantenga el gobierno de datos definido por su modelo de datos y sus políticas de acceso al contenido.

Para ofrecer una experiencia de datos eficaz, es fundamental que la gobernanza de datos sea impecable. Sigue leyendo para descubrir algunos conceptos y prácticas recomendadas que puedes usar para diseñar la experiencia que mejor se adapte a tus necesidades. Primero, te ofrecemos un breve resumen de cómo funciona todo esto.

Conceptos básicos sobre la inserción firmada de Looker

Es importante tener en cuenta que la autenticación y la gestión de usuarios de Looker en el contexto de inserción funcionan de la misma forma que en el contexto que no es de inserción y que la mayoría de las demás aplicaciones web.

Esto puede resultar confuso en el contexto de la inserción firmada de Looker, ya que el paso de autenticación firmada, la configuración de usuario y el propio panel se combinan en una URL larga y compleja. Sin embargo, esa URL se usa para establecer la sesión, que sigue aplicándose incluso después de que se acorte la URL. Tener en cuenta este concepto te ayudará a crear experiencias de datos excelentes.

Estructura de la URL insertada firmada

Esta es una de las URLs de autenticación de inserción firmadas generadas por la llamada create_sso_embed_url con el cuerpo de la solicitud de Pied Piper:

https://mylookerinstance.cloud.looker.com/login/embed/%2Fembed%2Fdashboards%2F17?permissions=%5B%22access_data%22%2C%22see_user_dashboards%22%5D&models=%5B%22thelook%22%5D&signature=iG6vcKBgnA50jaL2iShFeQHwFPN7wvTx7Rz6r%2FtFuvE%3D&nonce=%22967729518a7dbb8a178f1c03a3511dd1%22&time=1696013242&session_length=300&external_user_id=%22pied_piper%22&access_filters=%7B%7D&first_name=%22Pied%22&last_name=%22Piper%22&user_attributes=%7B%22brand%22%3A%22Pied+Piper%22%7D&force_logout_login=true

Esta es la misma URL decodificada y dividida en líneas individuales:

https://mylookerinstance.cloud.looker.com/login/embed/
/embed/dashboards/17
?permissions=["access_data","see_user_dashboards"]
&models=["thelook"]
&signature=iG6vcKBgnA50jaL2iShFeQHwFPN7wvTx7Rz6r/tFuvE=
&nonce="967729518a7dbb8a178f1c03a3511dd1"
&time=1696013242
&session_length=300
&external_user_id="pied_piper"
&access_filters={}
&first_name="PiedPiper"
&last_name="User"
&user_attributes={"brand":"Pied Piper"}
&force_logout_login=true

Cuando accedes a esta URL, ocurren varias cosas:

  1. Looker busca una cuenta de usuario con external_user_id = pied_piper. Si no existe ninguna, Looker crea una cuenta de usuario con ese external_user_id.

  2. Los detalles de la cuenta del usuario, incluidos los permisos, los modelos, los grupos (si se han especificado) y los valores de los atributos de usuario (si se han especificado), se sobrescriben con los detalles de la cuenta que se especifican en la URL.

  3. Looker autentica al usuario y establece una sesión para ese usuario almacenando una cookie de sesión en el navegador.

  4. A continuación, Looker redirige a la URL de destino o a la URL de redirección que se especifica en la llamada create_sso_embed_url:

    https://mylookerinstance.cloud.looker.com/embed/dashboards/17.

    Puedes ver esta URL de redirección como una URL relativa codificada en la URL de inserción firmada original:

    %2Fembed%2Fdashboards%2F17

Aunque los pasos del 1 al 3 se realizan automáticamente en segundo plano y el usuario final solo ve el resultado final (el propio panel de control), estos pasos son fundamentalmente los mismos que los que sigue un usuario normal de Looker que no usa la función de inserción para autenticarse. Supongamos que quieres que un usuario inicie sesión con credenciales de usuario y contraseña. El proceso sería similar al siguiente:

  1. Usted (el administrador de Looker) va al panel Administrar > Usuarios y usa la barra de búsqueda para comprobar si ya existe una cuenta de usuario para este usuario. Si no es así, crea una cuenta de usuario.

  2. Tú (el administrador de Looker) haces clic en Editar junto al usuario en el panel Administrar > Usuarios y le proporcionas permisos, modelos, grupos, valores de atributos de usuario y otros valores.

  3. El usuario va a la página de inicio de sesión en https://mylookerinstance.cloud.looker.com/login e introduce su nombre de usuario y su contraseña. Looker autentica al usuario y establece una sesión para ese usuario almacenando una cookie de sesión en el navegador.

  4. A continuación, Looker redirige a la página de destino (normalmente, https://mylookerinstance.cloud.looker.com/browse).

Ten en cuenta que la cookie de sesión se aplicará a todas las pestañas de la ventana del navegador. Si el usuario empieza en https://mylookerinstance.cloud.looker.com/browse, abre una nueva pestaña del navegador y va a cualquier página a la que tenga acceso según sus permisos, la página se cargará correctamente con la cookie de sesión que ya se había establecido en la pestaña original del navegador.

Lo mismo ocurre con los usuarios insertados. Los usuarios insertados tienen un acceso más limitado a las páginas de la interfaz de usuario. Solo pueden acceder a las URLs de looks, paneles de control y exploraciones con el prefijo /embed. Sin embargo, pueden ir manualmente a cualquier panel de control al que les permita acceder la información de su cuenta de usuario. Supongamos que la URL de inserción firmada original te redirige a https://mylookerinstance.cloud.looker.com/embed/dashboards/17 en una pestaña del navegador. A continuación, abre una nueva pestaña del navegador y carga otro panel de control insertado que se encuentre en la misma carpeta (y, por lo tanto, tenga las mismas restricciones de acceso): https://mylookerinstance.cloud.looker.com/embed/dashboards/19.

Aunque la URL de redirección especificada en la URL de inserción firmada original era del panel de control 17, puedes ver que el panel de control 19 se carga correctamente si introduces manualmente la URL en una pestaña del navegador. Ten en cuenta que no se ha necesitado otra URL de inserción firmada para cargar otro panel de control.

La clave es que todos los detalles de la cuenta de usuario establecidos en la URL (permisos, atributos de usuario, etc.) se aplican a toda la sesión del usuario, no solo al panel de control concreto especificado en la URL firmada original. En otras palabras, como su nombre indica, los atributos de usuario son una característica del usuario, no del panel de control, y deben usarse para determinar los niveles de acceso de un usuario específico en toda la aplicación, no solo en una pestaña concreta.

Acceder a varias marcas al mismo tiempo

Ten en cuenta que también tienes partners externos que pueden ser propietarios o gestionar varias marcas. En este ejemplo, un partner gestiona las marcas Pied Piper y Hooli.

El enfoque desde una perspectiva que no es de inserción

Las sesiones de usuario insertadas con firma funcionan básicamente de la misma forma que las sesiones de usuario de Looker normales (no insertadas), por lo que puede ser útil reformular el enfoque problemático descrito anteriormente en el contexto de una sesión de usuario de Looker normal (no insertada) y desglosar esos pasos para entender cómo implementar esta solución de una forma más sólida. Este sería el flujo de trabajo si le dieras instrucciones a un usuario de BI estándar que tiene acceso a la interfaz de Looker:

  1. Crea dos cuentas de usuario diferentes en la página Administrador > Usuarios.
    1. En la página de edición de la primera cuenta de usuario, asigna el valor pied_piper al atributo de usuario brand.
    2. En la página de edición de la segunda cuenta de usuario, asigna el valor hooli al atributo de usuario brand.
  2. Envías correos de configuración de la cuenta al partner para ambas cuentas de usuario.
  3. El partner configura credenciales de correo y contraseña independientes para cada cuenta.
  4. Proporciona al partner el enlace al panel de control. https://mylookerinstance.cloud.looker.com/dashboards/17) y dile que, para cambiar de marca en el panel de control, tendrá que volver a la página de inicio de sesión en otra pestaña e introducir las credenciales de correo y contraseña de su otra cuenta de usuario. Después, deberá volver a cargar el panel de control en esa pestaña.

El partner sigue las instrucciones. Sin embargo, después de introducir el nombre de usuario y la contraseña de la cuenta de usuario de Hooli en la segunda pestaña del navegador y volver a la primera pestaña, donde ya se había cargado el panel de control de Pied Piper, el partner pulsa el botón Recargar. Para sorpresa del partner, el panel de control muestra los datos de Hooli.

A estas alturas, puede que te estés preguntando:

Espera... esto es muy incómodo. ¿Cuál es la mejor forma de hacerlo?

¡Claro que sí! Estos casos prácticos ilustran un principio que ya es trivial en el contexto no insertado, pero que puede quedar oculto por las abstracciones del contexto insertado: un solo usuario humano debe estar asociado a una sola cuenta de usuario de Looker con un solo conjunto de valores de atributos de usuario. También se explica claramente en nuestra descripción del external_user_id en la documentación sobre la inserción firmada.

Looker usa external_user_id para diferenciar a los usuarios de inserciones firmadas, por lo que cada usuario debe tener un ID único asignado.

Puedes crear un external_user_id para un usuario con cualquier cadena que quieras, siempre que sea única para ese usuario. Cada ID está asociado a un conjunto de permisos, atributos de usuario y modelos. Un navegador solo puede admitir un external_user_id o una sesión de usuario a la vez. No se pueden hacer cambios en los permisos ni en los atributos de usuario durante una sesión.

Acceder a varias marcas al mismo tiempo: qué NO hacer

Como ocurre con cualquier solución personalizable, hay ciertos enfoques que debes evitar. Por ejemplo, una implementación en la que tu aplicación genera las URLs de ambos external_user_ids usando las mismas entradas en la llamada create_sso_embed_url que se ha mostrado anteriormente y crea una nueva pestaña en la aplicación para cargar cada panel de control al que necesite acceder el partner. Hemos observado que los desarrolladores suelen implementar soluciones como esta, lo que provoca que el flujo de trabajo del usuario sea incorrecto:

  1. Ve a la pestaña del panel de control de Pied Piper.
  2. Vaya a la pestaña del panel de control de Hooli.
  3. Vuelve a la pestaña del panel de control de Pied Piper.
  4. Pulsa el botón Volver a cargar en el panel de control de Pied Piper.

…el panel de control de Pied Piper muestra los datos de Hooli.

Puedes probar un enfoque similar, pero usando el mismo external_user_id test_user para ambas llamadas create_sso_embed_url. Sin embargo, el comportamiento es exactamente el mismo: una vez que se vuelve a cargar la pestaña con el panel de control de Pied Piper, se muestran los datos de Hooli.

¿Cómo puedo asegurarme de que el panel de control de cada marca muestre solo los datos de esa marca?

Aplicar las prácticas recomendadas

Para aplicar el método descrito en la sección El método desde una perspectiva no insertada, necesitará un único valor de atributo de usuario que conceda acceso a TODOS los datos a los que debe tener acceso el partner en la aplicación. Para ello, puede usar un valor separado por comas para el atributo marca Pied Piper,Hooli:

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "test_user",
  "first_name": "Test",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Pied Piper,Hooli"}
}

Para que esta sintaxis funcione, debe asegurarse de que su atributo de usuario esté definido como Filtro de cadena (avanzado):

Ten en cuenta que puedes cambiar el conjunto de atributos de usuario de un usuario si se modifican sus niveles de acceso a los datos. Por ejemplo, si el partner adquiere una tercera marca, puedes añadirla a la lista separada por comas que hayas especificado para el atributo de usuario brand. De esta forma, cuando cierren sesión y vuelvan a iniciarla, los cambios se aplicarán.

Filtrar los resultados del panel de control

De acuerdo, entiendo que los atributos de usuario deben especificar todos los datos a los que puede acceder un usuario en la aplicación. Pero si especifico los atributos de usuario de esta forma, se mostrarán los datos de todas esas marcas en mi panel de control. ¿Cómo puedo acotar los resultados de un panel de control concreto a una marca específica?

La forma correcta de filtrar un panel de control concreto es usar los filtros del panel de control. (Puede que ahora parezca obvio, pero hemos visto que algunos usuarios se han quedado atascados en los atributos de usuario como la única forma de aplicar filtros en el contexto de la inserción. Quizá sea porque user_attributes es un parámetro de la URL de inserción firmada y filters no lo es).

Asegúrate de que se requiera un valor de filtro y usa una de las opciones de control de selección individual, como el desplegable:

Asegúrate de que el filtro se aplique al campo correcto en todas las baldosas necesarias:

Ahora, tu partner puede elegir entre esos dos valores (y solo esos dos), ya que los atributos de usuario limitan las opciones disponibles en el menú desplegable:

Rellenar previamente los filtros del panel de control

Vale, ahora el panel de control se puede filtrar por una marca concreta, pero me gustaría que el valor del filtro ya estuviera definido en una marca específica cuando el usuario cargue el panel de control de esa marca en mi aplicación.

De nuevo, es útil pensar en cómo funciona en el contexto no insertado. ¿Cómo se envía a alguien un enlace a un panel de control que ya tiene aplicado un valor de filtro específico? Puede que haya observado que, al seleccionar un valor de filtro, este aparece en la URL del panel de control:

Incluye esa parte de la URL en tu target_url para la llamada create_sso_embed_url:

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17?Brand=Hooli",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "test_user",
  "first_name": "Test",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Pied Piper,Hooli"}
}

Si usas el SDK de inserción, puedes usar withFilters para especificar los filtros iniciales que se aplicarán al contenido insertado:

https://looker-open-source.github.io/embed-sdk/classes/EmbedBuilder.html#withFilters

Si usas tu propia secuencia de comandos personalizada, asegúrate de añadir el filtro a la URL antes de que se codifique la ruta. Es posible que algunos valores ya estén codificados en la cadena de filtro (por ejemplo, hay un espacio codificado como + en ?Brand=Pied+Piper), por lo que esos valores se codificarán dos veces en la URL final. Puedes consultar el artículo ¿Se puede definir un filtro de panel de control como parte de la URL de un panel de control insertado de SO? Publicación de la comunidad de Looker sobre algunas de estas sutilezas. Si sigues teniendo problemas para aplicar los filtros, en esa publicación de la comunidad también puedes hacer cualquier pregunta.

Ocultar los filtros del panel de control

Ya sé cómo definir los filtros iniciales en mis paneles de control, pero tampoco quiero que el partner cambie los filtros de los paneles de control. El valor del filtro SOLO debe determinarse en función del panel de control al que haya accedido el partner en mi aplicación. ¿Cómo puedo ocultar los filtros de los paneles de control?

Puedes usar temas para ello. Los temas son una función de pago, por lo que, si aún no la tienes habilitada en tu instancia de Looker, debes ponerte en contacto con tu equipo de Ventas de Looker para que la habilite.

Una vez que hayas habilitado esa función, ve a la sección Controles del panel de control de la página Administrar > Temas, donde puedes desactivar la opción Mostrar barra de filtros:

Después, puedes establecer el tema como predeterminado o aplicarlo en la URL de tus paneles de control específicos. De nuevo, esto se incluiría en el target_url de la llamada create_sso_embed_url:

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17?Brand=Hooli&theme=test_theme",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "test_user",
  "first_name": "Test",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Pied Piper,Hooli"}
}

En este tutorial de YouTube, Insertar Looker con filtros personalizados, encontrarás más información sobre cómo ocultar los filtros de los paneles insertados, incluidos algunos fragmentos de código del SDK de inserción.

El resultado final debe ser idéntico a la experiencia de usuario de la pregunta original:

Sin embargo, ahora, como los valores de los filtros están codificados en las URLs de destino correspondientes que están insertadas en la aplicación, el panel de control de cada marca siempre mostrará el panel de control filtrado por la marca correcta, incluso cuando cambies de una pestaña a otra.

Hacer pruebas como otros usuarios

Ahora la experiencia de usuario se parece mucho a lo que había imaginado. Sin embargo, en mi caso práctico, el partner tiene permisos diferentes y otros ajustes de usuario que no tienen los usuarios individuales con external_user_id=pied_piper y external_user_id=hooli, lo que conlleva que haya diferentes opciones disponibles en la interfaz de usuario y una experiencia de usuario ligeramente distinta en general. Quiero que un usuario vea todo exactamente igual que los usuarios de pied_piper y hooli, como si hubiera iniciado sesión con esas cuentas. ¿Cómo puedo hacerlo?

Si quieres que un usuario pueda hacer pruebas como cada uno de los usuarios de marca, puedes crear una función sudo similar en tu aplicación que cargue las URLs de inserción de external_user_id=pied_piper cuando el usuario esté usando sudo como usuario de Pied Piper y las URLs de inserción de external_user_id=hooli cuando el usuario esté usando sudo como usuario de Hooli. También puedes usar el endpoint de la API login_user para usar la API como superusuario de la marca si tu aplicación la utiliza.

Sin embargo, si vuelves a pensar en el contexto no insertado, en la página Administrar > Usuarios, no puedes usar sudo simultáneamente como varios usuarios no insertados en varias pestañas. La sesión de sudo se aplicará a toda la ventana del navegador, al igual que todas las demás sesiones de usuario. Por lo tanto, debes diseñar sudo para que solo un usuario pueda usar sudo a la vez. Además, si lo piensas, este diseño es más coherente con la imitación perfecta de la experiencia de los usuarios a los que estás suplantando. Por ejemplo, el usuario pied_piper solo tiene acceso al panel de control de Pied Piper y no puede abrir otros paneles en otras pestañas. Por lo tanto, tampoco deberías poder abrir diferentes paneles de control en diferentes pestañas cuando suplantas la identidad de este usuario.

Conclusión

Esperamos que esta guía te haya resultado útil y que te sientas preparado para seguir creando contenido insertado firmado de Looker. Trabajamos continuamente para que Looker sea la oferta de analíticas de datos insertadas más flexible y sólida, y nos gustaría conocer tu opinión. Si tienes alguna pregunta o quieres obtener más información, puedes ponerte en contacto con nosotros en la comunidad de Looker y asistir a nuestros eventos de la comunidad.