Soluciones · SaaS

Dirija su propio programa, en su propio sitio

Su equipo posee la hoja de ruta y ejecuta los tests. Pertento es la plataforma por debajo: una etiqueta de script, un editor visual y resultados que nadie tiene que creer a ciegas.

Dirigirlo usted mismo

Desde la primera tarde en adelante

Instalarlo, a quién invita, y cómo se publica un cambio cuando no hay tiempo de ingeniería para dedicarle.

Primeros pasos

En vivo desde la primera tarde

Una etiqueta de script en el head, y la consola empieza a informar. Nada que adquirir, ningún pipeline de datos que construir, ningún sprint de ingeniería que planificar.

  • Un rastreador de 0,9 KB, sin cookies, sin datos personales
  • El editor visual se ejecuta desde una extensión de Chrome en su sitio en vivo
  • Un nuevo experimento es un borrador hasta que lo inicia y publica el sitio web
La pantalla de implementación, que confirma que el rastreador está activo y detalla cómo está instalado: una etiqueta de script en el head, 0,9 KB, sin cookies.

El equipo

Invite a todos, pague por sesiones

El precio es por sesión en el sitio web, no por puesto, de modo que la diseñadora que escribe la variante y el analista que lee el resultado no cuestan nada más.

  • Usuarios ilimitados en todos los planes
  • Roles para quién puede iniciar, detener y publicar
  • Un registro de actividad de quién cambió qué
La pantalla de ajustes del equipo: cinco miembros con sus roles, sobre dos fichas que indican usuarios ilimitados y facturación por sesiones.

Sin ingeniería

Publique el cambio, entregue el ganador

La mayoría de las variantes nunca necesitan un desarrollador. Las que merece la pena conservar producen un ticket de implementación con el selector y el cambio exacto, de modo que la entrega es pegar en lugar de una reunión.

  • Edición sin código de texto, estilo, maquetación y posición
  • Entrega a implementación para los ganadores que merece la pena fijar en el código
  • El experimento sigue sirviéndose hasta que el código se publica
La cola de implementación: tres experimentos ganadores, uno pendiente de fijarse en el código, uno en curso y uno ya publicado.

En la práctica

Cómo es dirigirlo usted mismo un martes

La parte difícil de un programa interno rara vez es el primer test. Es mantener varios en marcha cuando experimentar no es el trabajo completo de nadie.

Su ritmo no lo limita el tráfico

Cada visitante elegible entra en cada test elegible, así que un equipo pequeño puede tener ocho test en marcha en un sitio mediano sin que ninguno tarde más en concluir. El consejo de lanzar uno a la vez es una limitación de otras herramientas.

Decide el backlog, no la voz más alta

Puntúe cada idea por potencial, exposición y esfuerzo, y la lista se ordena sola. Cuando nada está roto y nada espera una decisión, la consola le dice qué borrador retomar.

Solo lectura es un rol de verdad

Los miembros lo ven todo y no cambian nada, y eso es justo lo que hace seguro dar una cuenta a todo el equipo. Iniciar, detener y publicar quedan en manos de administradores y propietarios, y cada cambio se registra en el test con un nombre.

El segundo test sale más barato que el primero

Duplicar un test se lleva sus variantes, sus cambios, sus capturas y los tres tipos de segmentación. La mayor parte del coste de un programa es rehacer las configuraciones, y la mayoría de los errores están en la parte que se reconstruye a mano.

Nadie tiene que acordarse de pararlo

Programe el inicio y el final al construirlo. La parada al alcanzar significancia va aparte, con una duración mínima y una fecha de fin obligatoria, de modo que una parada temprana solo puede ser temprana y nunca lo único que termina un test.

Avisa cuando un test se rompe

Un reparto que ha dejado de coincidir con su configuración, o un día sin tráfico alguno, le llega por correo y por Slack en lugar de esperar a que alguien lo note. Ambas cosas suelen significar que un despliegue se llevó el script o que una regla de segmentación dejó de aplicar.

Preguntas

Antes de traerlo dentro de casa

¿Qué tan pequeño puede ser el equipo?

Una persona capaz de editar el sitio y leer un gráfico. El trabajo que normalmente exige un especialista es justo la parte que ya viene incorporada: el editor saca al desarrollador de la mayoría de las variantes, el orden del backlog saca la discusión sobre qué lanzar después, y la cola de lo que espera una decisión saca la revisión diaria de si algo se ha roto. Lo que no puede hacer es decidir qué merece la pena probar, y ninguna plataforma puede. Si nadie es dueño de esa pregunta, comprar software no creará un dueño.

¿Qué tendrán que hacer nuestros desarrolladores?

Tres cosas, y solo la primera es inevitable. Poner un script en el head, una vez, que es el único cambio en su sitio. Construir los test en el servidor, donde su propio backend decide qué se sirve, que son el único tipo de test hecho realmente de código. Y fijar los ganadores en el código cuando quieran que un cambio viva en su propia base de código en lugar de servirlo nosotros, algo que se entrega con el cambio exacto adjunto y es un pegar más que una reunión. Todo lo que hay en medio se hace señalando elementos en su sitio en producción.

¿Cómo se comporta el coste cuando crecemos?

Sigue al tráfico probado y no a la plantilla, así que las personas que hacen funcionar un programa no cargan cada una con un precio. La diseñadora que escribe la variante, el analista que lee el resultado y quien quiere seguirlo desde dirección pueden tener todos una cuenta, y los miembros son de solo lectura en toda la plataforma, así que repartir esas cuentas es seguro. Lo que crece con ustedes es el tráfico que pasan por test, que es la parte relacionada con lo que obtienen.

Ya tenemos GA4. ¿Esto lo sustituye?

No, y es mejor que lo conserven. Ponga el sitio en GA4 y el runtime lee los eventos que ya circulan por su capa de datos, de modo que las conversiones que medimos son las mismas que cuenta su analítica. Eso elimina la discusión habitual entre dos herramientas con dos definiciones de una compra. La exposición a la variante también se devuelve, así que un test se convierte en una dimensión por la que segmentar dentro de los informes en los que su equipo ya confía.

¿Qué pasa con el trabajo si lo dejamos?

Todo lo que ya está fijado en el código está en su propia base de código y no se toca, y precisamente por eso la cola de implementación insiste con los ganadores que aún servimos. Los ganadores que la plataforma todavía sirve se detienen cuando ella se detiene, igual que se detiene cualquier variante. Los test, las hipótesis que los originaron y el registro de cada decisión viven en la cuenta y no en la hoja de cálculo de un consultor: lo que se llevan es un programa documentado y no una carpeta de capturas.

Mejores test, mejores conversiones

Test on all visitors with the world’s lightest script and make confident decisions powered by real-time reporting.