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:
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">Fragen zum Upgrade</h2>
|
||||
<div class="cmp-faq-grid">
|
||||
<details class="cmp-faq">
|
||||
<summary>Ist ein Upgrade dasselbe wie ein Update?</summary>
|
||||
<summary class="plausible-event-name=FAQ">Ist ein Upgrade dasselbe wie ein Update?</summary>
|
||||
<div class="cmp-a">
|
||||
<p>
|
||||
Nein. Ein Update bringt Ihnen die neueste Fassung der Software, die Sie bereits einsetzen. Ein Upgrade bringt Ihre Datenbank auf eine neue Hauptversion (18 auf 19 oder 19 auf 20) und wandelt die Daten selbst um. Es geht nur in eine Richtung: einen unterstützten Weg zurück gibt es nicht, und es ist keine Lizenzänderung, kein Editionswechsel und kein Hosting-Wechsel.
|
||||
@@ -763,7 +763,7 @@ sudo -u postgres pg_restore -d <DB_NEW> /path/backup/<DB>.dump
|
||||
</div>
|
||||
</details>
|
||||
<details class="cmp-faq">
|
||||
<summary>Können wir direkt von Odoo 14 auf Odoo 20 upgraden?</summary>
|
||||
<summary class="plausible-event-name=FAQ">Können wir direkt von Odoo 14 auf Odoo 20 upgraden?</summary>
|
||||
<div class="cmp-a">
|
||||
<p>
|
||||
Nein. Es geht immer nur eine Hauptversion auf einmal: 14 auf 15 auf 16 auf 17 auf 18 auf 19 auf 20. Eine Version zu überspringen ist kein unterstützter Weg. Unser eigener Migrationsservice dokumentiert Unterstützung für Datenbanken auf Odoo 17, 18 und 19, nur Hauptreleases, keine Patch-Releases; ältere Datenbanken brauchen zuerst eine Kompatibilitätsprüfung, die mit einem Support-Ticket beginnt.
|
||||
@@ -771,7 +771,7 @@ sudo -u postgres pg_restore -d <DB_NEW> /path/backup/<DB>.dump
|
||||
</div>
|
||||
</details>
|
||||
<details class="cmp-faq">
|
||||
<summary>Was passiert mit meiner Historie: Rechnungen, Zahlungen, Anhänge?</summary>
|
||||
<summary class="plausible-event-name=FAQ">Was passiert mit meiner Historie: Rechnungen, Zahlungen, Anhänge?</summary>
|
||||
<div class="cmp-a">
|
||||
<p>
|
||||
Das ist die richtige Frage, und die ehrliche Antwort lautet: Es hängt vom Weg ab. Der OpenUpgrade-Weg — eine Versionsmigration auf Ihrem eigenen Server — nimmt die Datenbank mit und erhält die Historie und die Verknüpfungen zwischen den Datensätzen. Die OpenUpgrade-Dokumentation warnt, dass der andere Weg, Dokumente in ein neues System zu verschieben, nur einen Teil Ihrer Daten rettet und die Historie und die Verknüpfungen zwischen den Datensätzen verliert, zum Beispiel die Rechnungen je Kunde. Unser Service baut Ihnen eine neue Datenbank und bringt Ihre Daten hinein; unser Weg ist also der, nach dem Sie fragen sollten: Bitten Sie uns vor Ihrer Freigabe, genau aufzulisten, welche Datensätze in der neuen Datenbank sein werden und welche nicht. Wir möchten lieber, dass Sie sie stellen, als dass Sie sie annehmen.
|
||||
@@ -779,7 +779,7 @@ sudo -u postgres pg_restore -d <DB_NEW> /path/backup/<DB>.dump
|
||||
</div>
|
||||
</details>
|
||||
<details class="cmp-faq">
|
||||
<summary>Funktionieren meine individuellen Module weiterhin?</summary>
|
||||
<summary class="plausible-event-name=FAQ">Funktionieren meine individuellen Module weiterhin?</summary>
|
||||
<div class="cmp-a">
|
||||
<p>
|
||||
Nicht von allein. Ein Modul, das für Ihr Geschäft geschrieben wurde, braucht seinen Code auf der Zielversion, und Umbenennungen, die sonst Daten kosten würden, brauchen eigene Migrationsskripte. Die Odoo-Dokumentation ist hier deutlich: Ein Upgrade ist blockiert, bis es eine Version Ihrer individuellen Module für die Zielversion gibt. Module, die mit Odoo ausgeliefert werden, und Module der Community-Vereinigung bringen ihre eigenen Migrationsskripte mit; Ihre nicht, und die muss jemand schreiben.
|
||||
@@ -787,7 +787,7 @@ sudo -u postgres pg_restore -d <DB_NEW> /path/backup/<DB>.dump
|
||||
</div>
|
||||
</details>
|
||||
<details class="cmp-faq">
|
||||
<summary>Was kostet es, und wie lange dauert es?</summary>
|
||||
<summary class="plausible-event-name=FAQ">Was kostet es, und wie lange dauert es?</summary>
|
||||
<div class="cmp-a">
|
||||
<p>
|
||||
Für den Upgrade-Service veröffentlichen wir weder Preis noch Dauer, und wir erfinden hier auch keine. Was wir veröffentlichen, ist der Anfang: Sie eröffnen ein Support-Ticket, wir prüfen Ihre Datenbank auf Kompatibilität und melden uns bei Ihnen. Wenn Sie es gegen die Eigenleistung abwägen, ist der ehrliche Vergleich nicht die Servermiete, sondern Ihre eigenen Stunden, die auf keiner Rechnung auftauchen.
|
||||
@@ -795,7 +795,7 @@ sudo -u postgres pg_restore -d <DB_NEW> /path/backup/<DB>.dump
|
||||
</div>
|
||||
</details>
|
||||
<details class="cmp-faq">
|
||||
<summary>Brauche ich einen Entwickler?</summary>
|
||||
<summary class="plausible-event-name=FAQ">Brauche ich einen Entwickler?</summary>
|
||||
<div class="cmp-a">
|
||||
<p>
|
||||
Um die Befehle im technischen Abschnitt auszuführen, ja; oder jemanden, der sich im Terminal mit PostgreSQL auskennt. Damit wir es übernehmen, nein: Genau das ist der Sinn des Service. Sie senden die Datenbank, wir bauen das neue System auf unserer Infrastruktur, und Sie erhalten die Zugangsdaten.
|
||||
@@ -803,7 +803,7 @@ sudo -u postgres pg_restore -d <DB_NEW> /path/backup/<DB>.dump
|
||||
</div>
|
||||
</details>
|
||||
<details class="cmp-faq">
|
||||
<summary>Kann ich das System mit der neuen Version ansehen, bevor es live geht?</summary>
|
||||
<summary class="plausible-event-name=FAQ">Kann ich das System mit der neuen Version ansehen, bevor es live geht?</summary>
|
||||
<div class="cmp-a">
|
||||
<p>
|
||||
Ja, und das sollten Sie. Wer die Arbeit macht, migriert zuerst eine Kopie; das ist die erste Regel des ganzen Prozesses, in der Odoo-Dokumentation wie im OpenUpgrade-Projekt. Und die migrierte Kopie ist das, was Sie prüfen, bevor mit dem System, auf dem Ihr Geschäft läuft, irgendetwas passiert. Unser Service folgt demselben Prinzip: Wir bauen das neue System auf unseren eigenen Servern, und Sie vergleichen es mit dem alten.
|
||||
@@ -811,7 +811,7 @@ sudo -u postgres pg_restore -d <DB_NEW> /path/backup/<DB>.dump
|
||||
</div>
|
||||
</details>
|
||||
<details class="cmp-faq">
|
||||
<summary>Wir sind woanders gehostet. Können Sie uns trotzdem upgraden?</summary>
|
||||
<summary class="plausible-event-name=FAQ">Wir sind woanders gehostet. Können Sie uns trotzdem upgraden?</summary>
|
||||
<div class="cmp-a">
|
||||
<p>
|
||||
Ja, genau dafür ist unser Migrationsservice da. Sie eröffnen ein Support-Ticket, wir senden Ihnen ein sicheres Formular zum Hochladen Ihrer Datenbank, richten Ihnen einen neuen Server auf unserer Infrastruktur ein und stellen die Zugangsdaten bereit. Datenbanken auf Odoo 17, 18 und 19, nur Hauptreleases; ältere nach einer Kompatibilitätsprüfung.
|
||||
|
||||
Reference in new issue
Block a user