📒 Octus — Ledger
What this file is for: your context hand-off to me. Dump decisions, data, scope, and audit notes here. I read this before working on Octus. Bucket: 2X (Full Job) · Task tracking: Task Board
🔎 Snapshot
- Engagement: Maintenance (under 2X)
- Status: Active
👥 Stakeholders / Contacts
| Name | Role | Notes |
|---|---|---|
| Darwin | (Octus side) | State management — pending follow-up |
| Rosa Cortez | Colleague | Discussing login/sign-up tracking |
| Add… |
🛠️ Tools & Tech Stack
- CookiePro (consent management) · GTM (tag manager) · GA4 (analytics) · Okta (auth — login.octus.com) · Salesforce (form tracking via GTM)
📦 Scope & Deliverables — Pending
- CookiePro monitoring — improve the “Unknown geolocation” issue; if it can’t be improved, suggest enabling “Auto-block” from CookiePro.
- Follow up with Darwin regarding state management.
- Build a plan to track sign-up & login — see approach below.
- See also Octus - Maintenance
🔐 Sign-up & Login tracking — approach
Login lives outside the GTM setup, so it must be tracked in two places:
- “Clicked login” (intent) — already capturable on octus.com via existing GTM by tracking clicks on the login button. Tells us someone tried.
- “Actually logged in” (success) — happens on the Okta side (login.octus.com), which has no GTM. Most reliable route: use Okta as the source of truth (it logs every successful/failed login) and forward success events into GA4 (via GTM), keyed to the user. Gives a definitive “logged in” count tied to specific clients. May need GTM on the login page (same as the Salesforce form approach).
Next step: dig in to confirm the Okta route actually works; if it does, write up exact implementation instructions. (Source: comment thread w/ Rosa Cortez.)
🗂️ Decisions Log
| Date | Decision | Why | Owner |
|---|---|---|---|
| date |
🧾 Audit Trail
| Date | What happened | Detail / link |
|---|---|---|
| date |
📝 Context & Notes (dated)
- 2026-06-08: Ledger created.
❓ Open Questions
- …