DE{CODE}: Monitoreo del sitio: la intersección del producto, el diseño de UX y la investigación

¿No odias cuando descubres que tu sitio o el sitio de tu cliente está caído... de tu cliente? ¡No te dejes sorprender nunca más! Únase al gerente sénior de productos de WP Engine, Bryan Smith, a la investigadora asociada de UX, Kate Meyer, y al diseñador sénior de productos, Kameron Fehrmann, mientras analizan la solución de monitoreo del sitio de WP Engine, que hace que este problema sea una reliquia del pasado. En esta sesión, obtendrá una visión detallada de cómo funciona el monitoreo del sitio y cómo la intersección del diseño de UX, la investigación y el desarrollo de UX se unieron para garantizar el ajuste del producto al mercado.

Diapositivas de la sesión

Transcripción de texto completo

BRYAN SMITH : Hola a todos. Mi nombre es Bryan Smith. Soy gerente de producto aquí en WP Engine. Muchas gracias por acompañarnos hoy. Estamos aquí para hablarle sobre el monitoreo del sitio, la intersección del producto, el diseño de UX y la investigación. Me acompañan hoy Kate Meyer, una de nuestras investigadoras de UX, y Kameron Fehrmann, uno de nuestros diseñadores de productos. En la siguiente diapositiva, les hablaré sobre lo que es el monitoreo del sitio. Así que acabamos de lanzar este nuevo producto. Se llama "monitoreo del sitio". Está disponible como complemento para los clientes de WP Engine. Y con él, podrá monitorear cualquiera de los entornos de su sitio que estén asociados con su cuenta. Y le diremos si hay algún tipo de interrupción que veamos en el sitio o en nuestra plataforma.

Y a continuación, voy a repasar nuestra agenda muy rápido. Así que repasaré el producto y le daré una descripción general, así como una inmersión técnica profunda. Pero antes de eso, se lo pasaré a Kate Meyer para que nos cuente un poco cómo llegamos a este producto. Repasará algunas técnicas de investigación de usuarios que hemos utilizado. Luego se lo entregará a Kameron, quien revisará el diseño y la iteración de nuestro producto. Y luego terminaré con la descripción general del producto y una inmersión técnica profunda. A ti, Kate.

KATE MEYER : Muy bien. Gracias, Bryan, soy Kate. Soy un investigador de UX aquí en WP Engine, actualmente enfocado en mejorar nuestras ofertas de creación de sitios. Así que Bryan nos mostró este gran producto nuevo que tenemos ahora. Pero, ¿cómo terminamos aquí? Quiero volver al comienzo de nuestra línea de tiempo y demostrar cómo usamos el pensamiento de diseño para pasar de conocer la información básica sobre nuestros usuarios al lanzamiento del producto en solo unos meses. Me centraré en el aspecto de investigación de nuestro proceso y compartiré con usted cómo puede implementar estas prácticas sin importar cuál sea su función, incluso si no tiene un investigador de UX en su equipo.

Como mencioné, usamos estas tres fases del pensamiento de diseño para este proyecto. El pensamiento de diseño es un marco estándar de la industria. Eso es esencialmente un enfoque centrado en el usuario para resolver un problema. Voy a dividir nuestro trabajo en estas tres fases aquí. El verano pasado, queríamos aprender cómo no solo arreglar lo que estaba mal con el portal de usuario de WP Engine, sino aprender cómo podríamos llevarlo al siguiente nivel.

Entonces, para abordar esto, utilizamos la investigación generativa. Esto fue en forma de entrevistas con una variedad de nuestros usuarios. Les hicimos a todos un conjunto de preguntas escritas previamente, todas las mismas preguntas para todos los usuarios, solo para generar una comprensión de cosas como sus trabajos, objetivos, desafíos, etcétera. Si un proceso de entrevista le parece abrumador, también puede utilizar una herramienta de encuesta para el mismo propósito. De hecho, usamos SurveyMonkey junto con entrevistas como otra forma de obtener comentarios.

Durante esta fase de la investigación, encontramos muy interesante que, a pesar de las diferencias en los roles de los usuarios, en realidad compartían muchos objetivos comunes y puntos débiles. Y este es un gran patrón para ver. De hecho, queremos ver estas similitudes entre diferentes tipos de usuarios, porque nos ayuda a evaluar nuestro trabajo. Y mientras realizábamos estas entrevistas y encuestas, comenzamos a notar algunos temas comunes dentro del contexto del alojamiento de sitios web.

Dos de los objetivos de los que seguíamos escuchando eran querer una sola herramienta para monitorear y mantener sitios web y también detectar problemas antes de que los clientes y visitantes del sitio noten que algo anda mal. Sin embargo, un problema común fue que nuestro portal de usuario actualmente no permite a los usuarios cumplir con estos objetivos. Y, de hecho, el propietario de esta agencia lo resumió bastante bien al decir: “Si puedo resolver un problema antes de que el cliente lo vea, eso es fantástico. No quiero recibir esas llamadas de clientes de 'Oh, oye, ¿adivina qué? Fui a mi sitio web. No está ahí. ¿Qué harás hoy?'"

Una vez que vea que estos temas comunes surgen una y otra vez cuando escuche a los usuarios, entonces sabrá que es el momento de idear. Sabíamos que necesitábamos mejorar el portal de usuarios para ayudar a los usuarios a cuidar sus sitios de manera proactiva. Y también sabíamos que nuestro equipo de ingeniería podía aprovechar la tecnología de los socios para abordar un aspecto del punto débil de los usuarios, y eso era a través del monitoreo del tiempo de actividad.

Entonces, en este punto, hubiera sido muy fácil para nosotros simplemente sumergirnos y comenzar a construir algo de inmediato. Pero si desea crear lo correcto la primera vez, es importante seguir recibiendo comentarios y aportes de los usuarios durante esta fase. También es muy importante en esta fase que participe todo el equipo.

Desea generar algunas ideas geniales, pero también debe asegurarse de que sus ideas sean factibles y que aún se alineen con lo que sus usuarios realmente necesitan. Entonces, durante esta fase, nuestro diseñador trabajó con el equipo de ingeniería para tener una idea y garantizar su viabilidad para el monitoreo del sitio. Y luego, con el gerente de producto y el diseñador, planifico algunas pruebas de concepto para que podamos presentar nuestra idea a los usuarios.

La prueba de concepto es un tipo de investigación que te ayuda a saber si la idea que tienes coincide con las expectativas y necesidades de tus usuarios. Así que les mostramos nuestra idea y les hacemos preguntas al respecto. En este caso particular, usamos maquetas LE midfill como las que se ven a la izquierda aquí, que el diseñador creó con la ayuda del equipo de ingeniería. Pero lo mejor de este tipo de investigación es que puedes mostrar algo tan simple como un lápiz sobre un papel. Ni siquiera tiene que verse bien.

Esta técnica es realmente genial, porque permite a los usuarios centrarse en las ideas en lugar de la presentación visual. Y nuevamente, en esta fase, realmente queremos saber si su idea va en la dirección correcta. Y otro aspecto de esto es que no tienes que mostrárselo a decenas o cientos de personas. Puede usar tan solo cinco participantes para este tipo de investigación porque, en ese momento, debería comenzar a ver algunos temas comunes en sus reacciones a su idea.

Entonces, durante nuestra prueba de concepto, aprendimos que las expectativas de nuestros usuarios se estaban alineando con nuestros planes para este producto. Eso nos puso en una buena posición para comenzar a construirlo. Sin embargo, todavía queríamos recopilar comentarios, por lo que decidimos optar por una versión beta cerrada. Y lo que parece esto es que algunos usuarios optan por participar, agregan la función a su cuenta y luego les piden comentarios a lo largo de su proceso de uso de la nueva función. Entonces, tener este pequeño grupo de usuarios con acceso al producto es una excelente manera de probar la usabilidad del mismo, resolver errores y simplemente comprender cómo podría cumplir mejor con sus expectativas antes de que el producto se lance a todos. de los usuarios

Así que Kameron continuará la historia desde aquí. Pero antes de dejar atrás la pieza de investigación, quiero resumir lo que espero que se lleven de mi historia. De nuevo, este marco puede ayudarlo a pasar de comprender las necesidades del usuario a crear un nuevo producto. Y cualquier miembro de su equipo puede aprender de sus usuarios a través de varios métodos y en todas y cada una de las fases de un proyecto. Cuando mantiene a sus usuarios en el centro de la construcción, así es como se asegurará de que su producto sea lo más fácil posible para sus usuarios y de obtener una ventaja competitiva. Gracias. Kameron.

KAMERON FEHRMANN : Muchas gracias, Kate. Hola a todos. Soy Kameron. Soy un diseñador de productos sénior aquí en WP Engine. También trabajo con herramientas de construcción y nuestros productos de comercio electrónico, y estoy muy emocionado de hablarles hoy sobre el monitoreo de sitios. Así que aquí es donde estamos en nuestra línea de tiempo. Lo hemos analizado, realizado nuestra investigación generativa, realizado algunas pruebas de concepto y ahora lo hemos lanzado a la versión beta. Tenemos una encuesta que muestra que estamos escuchando a la gente, y este fue en realidad el punto en el que entré en el proyecto.

Rápidamente me puse al día con la investigación anterior. Kate y Bryan fueron súper instrumentales en esto. Honestamente, si no hubiéramos tenido ya algunas de las cadencias de colaboración establecidas entre el diseño y la investigación, el producto y la ingeniería, las cosas no habrían ido tan bien. Así que fueron grandes socios para ponerme al día en el medio. Sé que algunos de ustedes probablemente entienden cómo es eso, trabajar en la vida de una agencia. Sabíamos que esta base era genial para nuestra versión beta, pero queríamos hacer más con ella.

Así que hicimos un seguimiento rápido después de lanzar la versión beta para mejorar el diseño un poco más. En primer lugar, comenzamos con nuestro estado de WP Engine. Escuchamos de los usuarios que no estaban muy seguros de si las interrupciones que estaban experimentando se debían a algo que habían hecho internamente o si era un problema de WP Engine que, francamente, estaba fuera de su control. Así que agregamos este estado para que las personas pudieran ver, hey, algo está pasando con WP Engine. Somos nosotros, no tú o viceversa.

También agregamos la función Agregar, Eliminar o Pausar para monitorear. Básicamente, esta era una forma en que las personas agregaban o eliminaban monitores y luego también pausaban el monitoreo cuando era necesario, y era solo una forma en que las personas personalizaban un poco más su experiencia. Y, por último, como puede ver aquí, detectamos bastantes apagones. Queríamos asegurarnos de que las personas pudieran ver claramente lo que estaba sucediendo con sus sitios y definitivamente comunicarse con las personas. Y esto es algo que también escuchamos, que querían poder ver sus apagones y solucionar los problemas lo antes posible y lo más rápido posible.

Y aquí hay una especie de antes y después de donde empezamos con la beta y terminamos antes de lanzarla. Como puede ver, algunas diferencias bastante grandes. Nos centramos específicamente en las columnas. Escuchamos de personas que no entendían muy bien qué eran las columnas o para qué servían o qué significaban las cosas dentro de ellas.

Así que hicimos que el estado de la interrupción fuera mucho más claro en cuanto a si algo estaba o no en una interrupción y lo que eso significaba. Y luego también agregamos algunos enlaces más procesables. Agregamos la definición de lo que es una interrupción y luego un enlace a un artículo de soporte sobre el monitoreo del sitio para que las personas puedan ir y encontrar más información si así lo desean.

La otra cosa que hicimos fue relacionar esto más estrechamente con nuestro sistema de diseño interno. Fue genial poder extraer de una especie de biblioteca de componentes para mí como diseñador y desarrollador, para que pudiéramos hacer que nuestros flujos de trabajo fueran más rápidos. Si aún no tiene un sistema de diseño con el que está trabajando, le recomiendo uno. Simplemente hacen que sus flujos de trabajo sean mucho más fáciles y hacen que todo vaya mucho más rápido. Así que pudimos pasar de lo que ves a la izquierda a la derecha con bastante rapidez gracias a este sistema de diseño.

Y así es como se veía ese flujo de trabajo, esa iteración mientras trabajábamos en la versión beta. Así que empezamos. Liberamos. Recibía comentarios de nuestros usuarios con nuestra encuesta y también de los desarrolladores que trabajaban en el producto. Hice algunos cambios de diseño. Hablaría con la tríada. Podríamos tener algunos comentarios entre nosotros, y luego se los pasaría a los desarrolladores. Es posible que tengan algunos comentarios. Podríamos tener alguna discusión y luego lanzaríamos a beta y el ciclo comenzaría de nuevo.

Entonces, solo para registrarnos aquí, hemos pasado, lanzado a beta. Hemos escuchado a las personas en nuestra encuesta beta. Y ahora, estamos listos para comenzar con las alertas y obtener esa experiencia. Alertas, sabíamos que la gente quería alertas, necesitaba alertas. Esto fue algo que escuchamos de los usuarios, era muy importante y haría que el monitoreo fuera aún más valioso para ellos.

También sabíamos que los usuarios querían ser notificados de un problema antes de que sea un problema para sus clientes, algo así como escuchaste en nuestra cita. No quieren recibir una llamada de un cliente que diga que hay un problema o una interrupción en su sitio y que ellos mismos no lo sabían. Eso no es bueno.

La otra cosa sobre esto es que en realidad incluimos dos equipos de desarrollo más para este trabajo, porque queríamos poder cumplir con nuestro cronograma de lanzamiento. Ese ciclo que viste se volvió súper importante porque había más equipos. Más manos hacen el trabajo más ligero, pero también pueden complicar las cosas. Pero afortunadamente, pudimos encargarnos de eso para sus cadencias. Lo que teníamos que resolver con las alertas eran los canales que queríamos usar.

Lo que escuchamos de los usuarios principalmente fue que el correo electrónico era su canal preferido sobre Slack o SMS, por lo que decidimos seguir con los correos electrónicos primero. Y luego tuvimos que ir desde allí y pensar en todos los diferentes escenarios de correo electrónico. Queríamos asegurarnos de que nuestros mensajes fueran súper claros y prácticos para las personas, que pudieran entender y tomar medidas lo antes posible cuando recibieran una alerta.

La otra cosa en la que teníamos que pensar era que, cuando alguien se registra para recibir una alerta, queremos asegurarnos de que estamos confirmando que está suscrito. Esta es solo una especie de mejor práctica con la experiencia del usuario. Y luego, en el extremo opuesto, asegurándose de que la función de cancelación de suscripción sea bastante fluida para las personas y que sea una experiencia bastante fácil y buena, considerando todo. Entonces, sí, pasamos e hicimos más pruebas de usuario e investigamos un poco más para esto. Y realmente queríamos asegurarnos de que, como dije, el mensaje fuera comprensible y accionable.

Así que aquí está, de nuevo, solo un lado a lado de las pruebas antes y después. No hay muchas diferencias locas aquí. Principalmente, escuchamos de los usuarios que querían saber cuáles eran los errores específicos y que querían más información, así que eso es lo que tratamos de darles. Tratamos de darles los códigos de error y cualquier otra información que pudiéramos y simplemente aclaramos un poco ese contenido. Y después de esto, sinceramente, solo era cuestión de trabajar para el lanzamiento. Honestamente, solo quiero resaltar algunos de estos puntos clave de los que hablé y estos puntos clave de colaboración que tenemos a lo largo de este proyecto.

En primer lugar, el modelo operativo de la tríada era muy importante para nosotros. Una vez más, el diseño y la investigación, el producto y la ingeniería trabajaron juntos como un equipo para lanzar este producto. Con frecuencia tendríamos sincronizaciones y bases táctiles sobre diseño, investigación e ingeniería. Y haríamos preguntas, colaboraríamos.

Incluso creamos nuestro propio canal de Slack. Reconozco que no todos pueden o pueden hacer esto, pero crear esas relaciones de colaboración entre el diseño y el producto es realmente importante. Y son realmente clave para asegurarse de que tenga esa alineación y responsabilidad en ese nivel de empresa o agencia al crear productos.

La otra cosa que mencionaré es que el diseño y la investigación tienen una asociación tan estrecha. Reconozco que no todo el mundo trabaja con un diseñador o un investigador, pero aún puede ser un defensor de la experiencia del usuario si lo desea. Hay muchos grupos de UX que brindan excelentes recursos y mejores prácticas, por lo que aún puede ser un defensor de la usabilidad, incluso si no es su función principal o no es algo que hace con frecuencia.

La otra cosa que mencionaré es en realidad la asociación con el desarrollo. Trabajé muy de cerca con todos los equipos de desarrollo en este proyecto. A menudo me encontraba acudiendo a ellos, preguntándoles si estaba loco por crear un diseño o algo así, y siempre estaban muy abiertos a trabajar conmigo y me brindaban todo tipo de ideas, haciendo preguntas.

Fue grandioso. Tuvimos una gran relación de colaboración. Entonces diré, si estás trabajando con un diseñador, no dudes en ensuciarte las manos y colaborar con ellos. Nos encanta trabajar con desarrolladores que están dispuestos a sentarse allí y comprender los problemas que estamos tratando de resolver y trabajar juntos hacia ese objetivo común.

Otra cosa sobre eso, en realidad me involucré en muchas de las ceremonias y cadencias ágiles que tienen estos equipos. Así que poder sentarme, refinar la cartera de pedidos o planificar sprints y hacer preguntas, hacer que me hicieran preguntas en el contexto del trabajo de desarrollo fue muy valioso. Y por último, pero no menos importante, la colaboración asíncrona. Esto fue realmente clave. Somos una empresa global. Tenemos equipos en todo el mundo y todos estamos muy ocupados.

Por lo tanto, poder crear canales de Slack específicos en todos los equipos para que todos colaboráramos fue realmente clave. Kate y yo podríamos publicar sobre investigación y diseño. Podríamos obtener comentarios, hacer preguntas sin tener que esperar una revisión o una reunión. Y creo que solo quiero señalar eso, que la situación no tiene que ser perfecta, perfecta, disculpe, para que podamos colaborar. Puedes hacerlo de forma asíncrona. No es necesario esperar a una reunión. No todo tiene que estar exactamente bien para hacer las cosas. Así que ese es mi tiempo. Muchas gracias a todos. Bryan, voy a dejar que te lo lleves y hables sobre nuestra descripción general del producto.

BRYAN SMITH: Muchas gracias, Kameron. Está bien. Como prometí, pasaré a una descripción general del producto y luego haremos una inmersión técnica profunda antes de cerrar. Entonces sitio de monitoreo y portal. Aquellos que agreguen el complemento, tendrán acceso a una nueva página del portal. Se llama "monitoreo del sitio". Y desde esta página, puede agregar monitores, pausar y eliminar. Kameron aludió un poco a esto, pero esta es la página desde la que lo haces.

Además, desde esta página, podrá ver las interrupciones, el tiempo de actividad y el tiempo de respuesta promedio para un rango de fechas seleccionado. También podrá vincularse a registros de errores específicos del sitio cuando detectemos interrupciones, por lo que todo eso es posible desde esta página. También habrá enlaces a la página de Preferencias de alerta, a la que entraremos aquí en un segundo.

DE ACUERDO. Así que quiero saltar a un video muy rápido y luego volveremos a las diapositivas, pero esto será un recorrido de demostración real de cómo se ve esa página en el portal. Solo una cosa para señalar, se grabó antes de algunas de esas imágenes que viste de Kameron. Así que estamos actualizando esto. No tome esto exactamente como se ve, pero es una buena aproximación de lo que verá en el portal.

Menú. Verá un enlace de monitoreo del sitio. Abriremos esta página aquí y verán que tengo una lista de todos los entornos del sitio que estoy monitoreando. Puedo ver esos tiempos de respuesta y la lista de todos los que están monitoreados actualmente. Hice clic en el enlace de estado de WP Engine en la parte superior y me llevó a esta página de estado de WP Engine. Kameron también lo mencionó anteriormente, pero está disponible allí.

Cuando hago clic en el botón Agregar monitor, puedo hacerlo fácilmente con un solo clic. Diría que es una gran parte de este producto y la integración, es solo la facilidad con la que puede pausar, eliminar o aprovisionar monitores. Aquí, estoy pausando un monitor. Verás aparecer un pequeño botón de Reanudar allí. Sí. Si presiono Reanudar, se reinicia.

Y tenga en cuenta que una pausa realmente hace que el monitor de ping deje de hacer ping al sitio. Entonces, cada vez que está en pausa, en realidad no está enviando ese ping. Aquí, vamos a quitar un monitor. Verás una pantalla de confirmación. Porque cuando elimina uno de estos monitores, en realidad elimina todo el historial de interrupciones asociado con eso. Así que tenlo en cuenta.

Y esa es la página en el portal. Está bien. Ahora volveré a las diapositivas y hablaré un poco sobre la alerta por correo electrónico, así que hay algunas plantillas diferentes. Kameron aludió a esto un poco antes, pero profundizaré un poco más aquí. Entonces, una vez que opte por recibir alertas por correo electrónico, recibirá una plantilla de correo electrónico similar a esta, que muestra que ahora está suscrito para monitorear alertas para sus sitios. Le dará un enlace a nuestro artículo del Centro de soporte, que le dará más información sobre cómo funciona este producto. Y en la parte inferior, hay un enlace a la página de Monitoreo del sitio que les acabo de mostrar.

DE ACUERDO. Entonces, cuando detectemos una interrupción en su sitio, recibirá un correo electrónico similar a este. Tendrá el nombre del sitio, cuando detectamos la interrupción. También mostrará el estado de WP Engine. Ahora bien, este estado es importante, porque le mostrará el estado actual de la plataforma, de la plataforma de alojamiento. Entonces, si esto se ve bien pero aún recibe este correo electrónico, eso indica que en realidad hay un problema específico del sitio.

No es específico de la infraestructura de alojamiento, pero en realidad hay algo en su sitio o su dominio. Y en el contenido del correo electrónico aquí, le mostrará ese código de respuesta que estamos viendo. Y luego, en la parte inferior, habrá un enlace a esa página de Monitoreo del sitio. También hay un enlace a los registros de acceso, porque este será su próximo mejor paso para tratar de diagnosticar lo que está sucediendo y por qué está viendo este correo electrónico de interrupción.

Está bien. Y luego, cuando eso se resuelva, verá otro correo electrónico que le muestra que su sitio está respaldado. La interrupción ya no se produce. Ya no lo estamos detectando. Esto también le dirá qué sitio está respaldado. Le dirá cuánto tiempo estuvo inactivo ese sitio y, nuevamente, los enlaces en la parte inferior. Mismos enlaces abajo en la parte inferior.

Así que mencioné que esta es una página a la que puede acceder desde la página y el portal de Monitoreo del sitio. Aquí es donde realmente configura sus preferencias de alerta. Entonces, desde aquí, puede habilitar o deshabilitar los canales de alerta. Puede ingresar contactos de correo electrónico. Los contactos de correo electrónico provienen de la lista de usuarios de su portal, por lo que lo verá en la parte inferior izquierda. Es solo una casilla de verificación.

Ya tenemos el nombre y la dirección de correo electrónico. No tienes que ingresar eso. Nuevamente, está sacando eso de los contactos de su portal. Pero mencione aquí que esta será una página desde la cual puede habilitar la integración de Slack. Todavía no lo tenemos, pero está en nuestra hoja de ruta. Es algo en lo que estamos a punto de empezar a trabajar. Actualmente, solo alertas por correo electrónico, pero Slack está en la hoja de ruta.

Está bien. Mencioné que entraríamos en algunos detalles técnicos aquí para darles una idea de cómo funciona todo esto detrás de escena. Entonces, todo es posible a través de lo que llamamos nuestro "Agente de monitoreo del sitio", y esta es una capa intermedia entre nuestro portal de usuario y lo que el usuario está haciendo allí y nuestro socio New Relic, cuyas API de monitoreo y alerta estamos consumiendo. Entonces, Site Monitoring Agent esencialmente centraliza los recursos de New Relic.

Esta es la capa que crea, actualiza y elimina monitores y alertas. Y también es el lugar donde podemos conciliar y detectar cualquier tipo de error, asegurándonos de que nada se elimine accidentalmente. Así que esta es esa capa intersticial, así que entremos un poco en algunas de las cosas que están sucediendo en un flujo de usuario. Así que veamos un flujo de usuario típico. Entonces un usuario se registrará. Lo que sucede allí es que se realiza una verificación de derechos en el portal para ver si tienen acceso a la supervisión del sitio.

Y en el caso de que lo hagan, verifica el servicio de autorización de WP Engine para obtener el visto bueno. Una vez que pasa esa verificación, el usuario puede crear un monitor desde esa página de Monitoreo del sitio que le mostré anteriormente en el portal. Así que aprovisionan manualmente ese monitor haciendo clic en el botón Agregar monitor. Y detrás de escena, está enviando una solicitud a la API de New Relic Synthetics para realmente aprovisionar ese monitor.

Ahora, mientras también está en esa página en el portal, puede ver los datos. Puede ver datos históricos. Por lo que hemos visto al hacer ping al sitio que configuró, también puede ver el tiempo de respuesta promedio, enlazar para acceder a los registros. Aquí, un cliente puede ver esos datos en esa página. Lo que sucede detrás de escena es que en realidad estamos accediendo a una API de New Relic diferente. Es su API NerdGraph. Entonces, Site Monitoring Agent envía una solicitud para recuperar esos datos y mostrarlos. Y todo eso está sucediendo, nuevamente, a través de la API de NerdGraph a través de New Relic.

Un par de otros casos de uso que serían comunes serían el escenario Edit Monitor. Entonces, esto podría estar pausando un monitor existente, en cuyo caso el agente enviará una solicitud de parche a la API de New Relic Synthetics. También puede desaprovisionar un monitor. Esto sería eliminar un monitor de esa página del portal que les mostré anteriormente. Esto es enviar una solicitud de eliminación a esa API de Synthetics. Un cliente también puede cambiar la configuración. Tal vez desee cambiar la URL del dominio al que estamos enviando esa verificación de ping.

En este caso, el agente envía una solicitud de parche para actualizar ese monitor. Además, un usuario puede cancelar el sitio que tiene monitoreo del sitio. Y en este caso, lo que estaríamos haciendo sería simplemente enviar una solicitud de eliminación automáticamente a esa API de Synthetics para desaprovisionar ese monitor. O en el caso de que un cliente pueda cancelar toda la cuenta que tiene un montón de monitores de sitio diferentes, se envía automáticamente una solicitud para desaprovisionar todos esos monitores cuando se detecta. Todas estas cosas son importantes para el flujo de usuarios, y Site Monitoring Agent es lo que lo hace posible.

Está bien. Así que lo mencioné anteriormente pero, mirando hacia el futuro, ciertamente estamos planeando integrar Slack como un canal de alerta adicional. También estamos explorando SMS, así que manténgase atento a más adiciones en el futuro. Este es nuestro V1. Estamos entusiasmados con esto y muy contentos de poder lanzarlo aquí en DE{CODE}. Pero esto realmente es V1. Tenemos tantos planes en la tienda. Estos son solo algunos de ellos. Pero también estén atentos a más opciones de configuración con el monitoreo, más mejoras al portal de usuario, y continuaremos siguiendo ese proceso iterativo de investigación y diseño que nos ha llevado a este punto.

Con eso, gracias a los otros presentadores, Kate y Kameron. Y gracias a todos por acompañarnos hoy. Que tengan un buen día y vayan a revisar el monitoreo del sitio. Gracias a todos.