Public Access
feat(analytics): add Plausible custom-event markings for six goals
Mark the six conversion goals on the self-hosted Plausible instance so the
events match the goals to be registered in Plausible. Event names verbatim:
Trial, FAQ, Buy, Custom Quote, search posts, Project Plan.
CSS-class markings (work without JS logic, on the clickable element):
- FAQ -> index/de/es index .faq-card; odoo-hosting-2027 + odoo-community-upgrade
(de/es twins) and australia <summary>; support.html .faq-question
- Buy -> index/de/es index .btn-buy anchors; australia + bootcamp native
post_basket submit buttons (forms stay native POST)
JS call markings in script.js (loaded by index, de/index, es/index):
- Trial on the successful trial-form POST (.then branch)
- Custom Quote on the successful custom-quote POST (.then branch)
- Project Plan on the successful business-wizard submit
- search posts on the FIRST input of #blogSearch only (guard flag, one per
pageview, not on every keystroke, not on #ocaSearch)
Nothing fires on page load; the 'Start the free trial' anchors that only
scroll to #trialCard are deliberately not tagged. One goal per topic across
all languages, no language suffix. No visual, behavioural or request change.
This commit is contained in:
webmaster committed
1 parent
ea97e65416
commit
73b3f34696
13 files changed
+104
-96
No files matched your search
@@ -755,7 +755,7 @@ sudo -u postgres pg_restore -d <DB_NEW> /path/backup/<DB>.dump
|
||||
<h2 class="section-title">Preguntas sobre el cambio de versión</h2>
|
||||
<div class="cmp-faq-grid">
|
||||
<details class="cmp-faq">
|
||||
<summary>¿Es lo mismo un cambio de versión que una actualización?</summary>
|
||||
<summary class="plausible-event-name=FAQ">¿Es lo mismo un cambio de versión que una actualización?</summary>
|
||||
<div class="cmp-a">
|
||||
<p>
|
||||
No. Una actualización le da la última revisión del software que ya utiliza. Un cambio de versión lleva su base de datos a una nueva versión mayor (18 a 19, o 19 a 20) y transforma los propios datos. Es en un solo sentido: no existe una vuelta atrás con soporte, y no es un cambio de licencia, ni de edición, ni de hosting.
|
||||
@@ -763,7 +763,7 @@ sudo -u postgres pg_restore -d <DB_NEW> /path/backup/<DB>.dump
|
||||
</div>
|
||||
</details>
|
||||
<details class="cmp-faq">
|
||||
<summary>¿Podemos pasar directamente de Odoo 14 a Odoo 20?</summary>
|
||||
<summary class="plausible-event-name=FAQ">¿Podemos pasar directamente de Odoo 14 a Odoo 20?</summary>
|
||||
<div class="cmp-a">
|
||||
<p>
|
||||
No. Se hace una versión mayor a la vez: 14 a 15 a 16 a 17 a 18 a 19 a 20. Saltarse una versión no es un camino con soporte. Nuestro propio servicio de migración documenta soporte para bases de datos en Odoo 17, 18 y 19, solo versiones principales, sin versiones de parche; las bases más antiguas necesitan antes una revisión de compatibilidad, que empieza con una incidencia de soporte.
|
||||
@@ -771,7 +771,7 @@ sudo -u postgres pg_restore -d <DB_NEW> /path/backup/<DB>.dump
|
||||
</div>
|
||||
</details>
|
||||
<details class="cmp-faq">
|
||||
<summary>¿Qué pasa con mi historial: las facturas, los pagos, los archivos adjuntos?</summary>
|
||||
<summary class="plausible-event-name=FAQ">¿Qué pasa con mi historial: las facturas, los pagos, los archivos adjuntos?</summary>
|
||||
<div class="cmp-a">
|
||||
<p>
|
||||
Esa es la pregunta correcta, y la respuesta honesta es que depende de la ruta. La ruta de OpenUpgrade — una migración de versión ejecutada en su propio servidor — lleva la base de datos consigo y conserva el historial y los enlaces entre registros. La documentación de OpenUpgrade advierte de que la otra ruta, trasladar documentos a un sistema nuevo, recupera solo parte de sus datos y pierde el historial y los enlaces entre registros, por ejemplo las facturas de cada cliente. Nuestro servicio le construye una base de datos nueva y traslada sus datos a ella, así que la nuestra es la ruta por la que preguntar: antes de aprobar nada, pídanos que enumeremos exactamente qué registros estarán en la nueva base de datos y cuáles no. Preferimos que la haga a que la dé por supuesta.
|
||||
@@ -779,7 +779,7 @@ sudo -u postgres pg_restore -d <DB_NEW> /path/backup/<DB>.dump
|
||||
</div>
|
||||
</details>
|
||||
<details class="cmp-faq">
|
||||
<summary>¿Seguirán funcionando mis módulos personalizados?</summary>
|
||||
<summary class="plausible-event-name=FAQ">¿Seguirán funcionando mis módulos personalizados?</summary>
|
||||
<div class="cmp-a">
|
||||
<p>
|
||||
No por sí solos. Un módulo escrito para su negocio tiene que llevar su código a la versión de destino, y los cambios de nombre que de otro modo perderían datos necesitan sus propios scripts de migración. La documentación de Odoo es tajante al respecto: un cambio de versión queda bloqueado hasta que exista una versión de sus módulos personalizados para la versión a la que se muda. Los módulos que vienen con Odoo y los de la asociación de la comunidad traen sus propios scripts de migración; los suyos no, y alguien tiene que escribirlos.
|
||||
@@ -787,7 +787,7 @@ sudo -u postgres pg_restore -d <DB_NEW> /path/backup/<DB>.dump
|
||||
</div>
|
||||
</details>
|
||||
<details class="cmp-faq">
|
||||
<summary>¿Cuánto cuesta y cuánto tarda?</summary>
|
||||
<summary class="plausible-event-name=FAQ">¿Cuánto cuesta y cuánto tarda?</summary>
|
||||
<div class="cmp-a">
|
||||
<p>
|
||||
No publicamos ni precio ni duración para el servicio de cambio de versión, y no vamos a inventarnos ninguno aquí. Lo que sí publicamos es cómo empieza: usted abre una incidencia de soporte, revisamos la compatibilidad de su base de datos y le respondemos. Si lo compara con hacerlo usted mismo, la comparación honesta no es el alquiler del servidor, sino sus propias horas, que nunca aparecen en esa factura.
|
||||
@@ -795,7 +795,7 @@ sudo -u postgres pg_restore -d <DB_NEW> /path/backup/<DB>.dump
|
||||
</div>
|
||||
</details>
|
||||
<details class="cmp-faq">
|
||||
<summary>¿Necesito un desarrollador?</summary>
|
||||
<summary class="plausible-event-name=FAQ">¿Necesito un desarrollador?</summary>
|
||||
<div class="cmp-a">
|
||||
<p>
|
||||
Para ejecutar los comandos de la sección técnica, sí; o alguien que se maneje en una terminal con PostgreSQL. Para que lo hagamos nosotros, no: de eso se trata el servicio. Usted envía la base de datos, nosotros montamos el sistema nuevo en nuestra infraestructura y usted recibe las credenciales.
|
||||
@@ -803,7 +803,7 @@ sudo -u postgres pg_restore -d <DB_NEW> /path/backup/<DB>.dump
|
||||
</div>
|
||||
</details>
|
||||
<details class="cmp-faq">
|
||||
<summary>¿Puedo ver el sistema con la nueva versión antes de ponerlo en producción?</summary>
|
||||
<summary class="plausible-event-name=FAQ">¿Puedo ver el sistema con la nueva versión antes de ponerlo en producción?</summary>
|
||||
<div class="cmp-a">
|
||||
<p>
|
||||
Sí, y debería hacerlo. Quien hace el trabajo migra primero una copia; esa es la primera regla de todo el proceso, tanto en la documentación de Odoo como en el proyecto OpenUpgrade. Y la copia migrada es lo que usted revisa antes de que le ocurra nada al sistema con el que funciona su negocio. Nuestro servicio sigue el mismo principio: montamos el sistema nuevo en nuestros propios servidores y usted lo compara con el antiguo.
|
||||
@@ -811,7 +811,7 @@ sudo -u postgres pg_restore -d <DB_NEW> /path/backup/<DB>.dump
|
||||
</div>
|
||||
</details>
|
||||
<details class="cmp-faq">
|
||||
<summary>Estamos alojados en otro sitio. ¿Pueden cambiar de versión igualmente?</summary>
|
||||
<summary class="plausible-event-name=FAQ">Estamos alojados en otro sitio. ¿Pueden cambiar de versión igualmente?</summary>
|
||||
<div class="cmp-a">
|
||||
<p>
|
||||
Sí, exactamente para eso está nuestro servicio de migración. Usted abre una incidencia de soporte, le enviamos un formulario seguro para subir su base de datos, le montamos un servidor nuevo en nuestra infraestructura y le damos las credenciales. Bases de datos en Odoo 17, 18 y 19, solo versiones principales; las más antiguas, tras una revisión de compatibilidad.
|
||||
|
||||
Reference in new issue
Block a user