If you’re building on Base44 and you think you have analytics… you probably don’t.

Most apps track pageviews (maybe) and then wonder:

• Which button is actually getting clicked?
• Where are people dropping off?
• Why is sign-up conversion low?
• Which traffic source is producing buyers (not just visitors)?
• What actions predict retention?

This guide gives you a repeatable workflow to make Base44 AI act like:

✅ analytics strategist
✅ user experience researcher
✅ conversion analyst

…and generate a complete measurement plan for:

• Pages to track
• Events to track
• Conversions (primary + micro)
• Funnels and drop-off points
• User journeys
• Attribution essentials (traffic source / campaigns)
• Naming conventions
• A prioritized implementation plan

This is NOT a one-shot prompt. It’s a multi-step workflow so the AI doesn’t mix strategy + code and make a mess.

The Workflow (3 Phases)

Phase 1 — Discovery Audit

AI scans the app and identifies:

• page types
• key user flows
• important actions
• conversion points
• tracking gaps and blind spots

Phase 2 — Tracking Strategy Report

AI turns the audit into a formal plan:

• page tracking list
• event taxonomy
• conversions + definitions
• funnels
• properties/parameters
• segments and audiences
• QA rules and guardrails

Phase 3 — Implementation Blueprint (Optional)

AI converts the plan into build tasks:

• where each event fires
• required properties
• anti-duplicate rules
• QA checklist
• reporting recommendations

(Then you can optionally generate code after you approve the plan.)

Before You Start (Do This or You’ll Waste Time)

What to give the AI

• Your app pages (or app export / page list)
• Your core goal (leads, signups, paid subscriptions, bookings, etc.)
• Your primary user types (example: visitor, free user, paid user, admin)
• Any existing analytics tool you’re using (Base44 Analytics, GA4, PostHog, etc.)

What not to do

• Don’t ask for dashboards first.
• Don’t ask for code first.
• Don’t track 200 events “just because.”

You want tracking that supports decisions.

Phase 1 Prompt — Analytics Audit (Discovery Pass)

Run this first.

You are a senior digital analytics strategist and conversion optimization analyst working inside a Base44 web app.

Your job is to audit this website/web app and produce a detailed analytics tracking audit report that identifies what SHOULD be tracked to fully understand user behavior, engagement, and conversions.

IMPORTANT:
- Do NOT build dashboards yet.
- Do NOT write final implementation code yet.
- First, analyze the app/site structure, pages, user flows, and conversion opportunities.
- Assume the goal is to create a complete analytics measurement plan for marketing, product, and sales decisions.
- Focus on practical tracking that helps decision-making, not vanity metrics.

==================================================
GOAL
==================================================
Audit the site/app and determine:
1) What pages/screens should be tracked
2) What user actions/events should be tracked
3) What conversions/micro-conversions should be tracked
4) What funnels and journeys should be measured
5) What key gaps/risks exist if tracking is missing

==================================================
WHAT TO REVIEW
==================================================
Review the full site/app experience, including:
- Landing pages / marketing pages
- Navigation/header/footer interactions
- Signup/login/auth flows
- Onboarding flows
- Forms (contact, lead, quote request, checkout, signup, etc.)
- Search/filter/sort interactions
- CTAs (buttons, links, sticky bars, banners)
- Product/service pages
- Pricing pages
- Checkout/payment flows (if applicable)
- Account/settings pages
- Dashboard pages
- Feature usage actions
- Error states / empty states
- Support/help/contact interactions
- Any messaging/social/profile interactions (if present)

==================================================
ANALYTICS AUDIT LENS (MUST APPLY)
==================================================

A) PAGE / SCREEN TRACKING
Identify all page/screen types that need tracking, including:
- page purpose
- primary CTA
- secondary CTA
- business value of the page
- likely user intent on that page

B) EVENT TRACKING
Identify meaningful user actions worth tracking, including:
- navigation interactions
- CTA clicks
- form interactions (start, submit, success, error, abandon)
- search/filter usage
- media engagement (video plays, scroll depth if relevant)
- account actions
- feature usage actions
- social/community actions (post, comment, follow, message, like, share)
- payment/checkout actions
- outbound clicks
- support interactions

C) CONVERSION TRACKING
Identify:
- primary conversions (revenue/lead generating)
- secondary conversions (micro-conversions)
- activation milestones
- retention signals
- re-engagement signals

D) FUNNEL / JOURNEY TRACKING
Map key journeys, such as:
- visitor → lead
- visitor → signup
- signup → activated user
- user → paying customer
- user → repeat usage
- feature discovery → feature adoption

E) DATA QUALITY / TRACKING GAP RISKS
Call out likely blind spots, such as:
- no tracking for CTA performance
- no funnel visibility
- missing error tracking
- no attribution capture
- duplicate events risk
- inconsistent naming risk
- missing user/property context

==================================================
DELIVERABLE FORMAT (REQUIRED)
==================================================
Respond with these sections:

1) ANALYTICS AUDIT SUMMARY
- What the app/site appears to do
- Primary business goals inferred
- Primary user types inferred
- Top 10 tracking opportunities
- Top 10 tracking risks/gaps

2) PAGE TRACKING INVENTORY (AUDIT)
For each page/page type:
- Page / screen name
- Purpose
- Primary user intent
- Primary CTA(s)
- Should track page view? (Yes/No)
- Business importance (High/Medium/Low)
- Notes (special tracking considerations)

3) EVENT TRACKING OPPORTUNITIES (AUDIT)
List all recommended events found during audit:
- Event candidate name (human readable for now)
- Where it happens (page/component)
- What user action triggers it
- Why it matters
- Priority (Critical/High/Medium/Low)

4) CONVERSION MODEL (AUDIT)
- Primary conversions
- Micro-conversions
- Activation milestones
- Retention events
- Revenue events (if applicable)

5) FUNNELS TO MEASURE
List recommended funnels with:
- Funnel name
- Steps
- Drop-off risks
- Business value

6) TRACKING GAPS / RISKS
- Missing visibility areas
- Data quality risks
- Instrumentation pitfalls to avoid

7) NEXT STEP RECOMMENDATION
State that the next step is generating a formal analytics tracking plan with event schema, naming convention, and required properties.

Begin the analytics audit now.

What you should get back

• A page inventory
• A big list of “events you should track”
• Conversion suggestions (primary + micro)
• Funnels (with step recommendations)
• Gaps (what you’re blind to today)

Do NOT implement yet.

Phase 2 Prompt — Formal Tracking Plan (Measurement Spec)

Run this after Prompt 1.

Use the analytics audit findings as the source of truth.

You are now a senior analytics implementation strategist. Create a formal analytics tracking plan/report for this Base44 app/site.

IMPORTANT:
- Do NOT write code yet.
- Create a complete, implementation-ready measurement specification.
- The plan should support marketing, product, sales, and UX optimization decisions.
- Prioritize clarity, naming consistency, and data quality.

==================================================
GOAL
==================================================
Transform the audit findings into a complete analytics tracking strategy including:
- page tracking plan
- event taxonomy
- conversion definitions
- funnels
- event properties / parameters
- user properties
- naming conventions
- QA requirements
- reporting recommendations

==================================================
TRACKING DESIGN RULES (MUST FOLLOW)
==================================================

1) TRACK FOR DECISIONS, NOT VANITY
Every event should support a real business/product decision.

2) CONSISTENT NAMING
Use a clear naming convention that is:
- readable
- consistent
- scalable
- easy for non-developers to understand

3) AVOID DUPLICATES
Define exact trigger conditions so events don’t fire twice.

4) DEFINE SUCCESS STATES
Track both attempt and outcome when relevant:
- started
- submitted
- succeeded
- failed

5) CAPTURE CONTEXT
Include useful event properties (page, source, item type, plan selected, etc.) without over-collecting noise.

6) PRIVACY / SAFETY
Do not recommend capturing sensitive personal data in analytics events.
Do not store secrets, passwords, payment card data, or private message content.

==================================================
REQUIRED OUTPUT FORMAT
==================================================

1) MEASUREMENT STRATEGY SUMMARY
- Business goals supported by tracking
- Primary user types / segments
- Key decisions this tracking enables

2) PAGE TRACKING PLAN
For each page/page type:
- Canonical page name
- Page category (marketing/auth/dashboard/settings/etc.)
- Track page view? (Yes/No)
- Key page properties to capture (example values)
- KPIs for this page

3) EVENT TAXONOMY (MASTER LIST)
Create a structured event list grouped by category:
- Navigation Events
- Engagement Events
- Form Events
- Auth Events
- Conversion Events
- Commerce/Payment Events (if applicable)
- Feature Usage Events
- Error/Failure Events
- Support Events
- Social/Community Events (if applicable)

For each event include:
- Event name (final proposed name)
- Event category
- Trigger condition (exactly when it fires)
- Where it fires (page/component/flow)
- Why it matters
- Priority (Critical/High/Medium/Low)
- Required properties
- Optional properties
- Conversion impact? (Yes/No)
- QA notes (duplication / edge cases)

4) CONVERSION DEFINITIONS
Define each conversion clearly:
- Conversion name
- Type (Primary / Micro / Activation / Retention / Revenue)
- Exact success criteria
- Associated events
- Attribution notes (what traffic/source context should be captured)

5) FUNNEL DEFINITIONS
For each funnel:
- Funnel name
- Funnel goal
- Step-by-step events/pages
- Entry conditions
- Exit conditions
- Drop-off points to monitor
- Recommended segmentation (device, source, campaign, user type, etc.)

6) USER PROPERTIES / CONTEXT PROPERTIES
Recommend tracked user-level and session/event context properties, such as:
- user_type
- account_status
- plan_tier
- signup_method
- traffic_source / campaign info
- device type
- app version (if applicable)

For each property:
- Property name
- Scope (user/session/event)
- Why it matters
- Example values

7) ANALYTICS QA PLAN
Provide a QA checklist to validate:
- correct triggers
- no duplicate firing
- property population
- success/failure events
- funnel continuity
- conversion accuracy
- cross-device/mobile coverage

8) PRIORITIZED IMPLEMENTATION ROADMAP
Group implementation into phases:
- Phase 1: must-have tracking (critical)
- Phase 2: conversion/funnel optimization tracking
- Phase 3: advanced product analytics / retention tracking

9) DASHBOARD / REPORT RECOMMENDATIONS (NO BUILD, JUST PLAN)
Recommend reports to create later:
- Acquisition
- Landing page performance
- CTA performance
- Funnel conversion
- Form performance
- Activation/retention
- Revenue/conversion performance
- Error monitoring overview

Now generate the formal analytics tracking plan.

What you should get back

This should read like a real measurement spec:

• consistent event names
• required properties
• conversion definitions
• funnel step mapping
• QA checklist
• prioritized phases

Now you review it and trim it down.

Phase 3 Prompt — Implementation Blueprint (Optional)

Use this if you want the AI to turn the plan into “build tasks”.

Use the approved analytics tracking plan as the source of truth.

Create an implementation blueprint for Base44 analytics instrumentation.

IMPORTANT:
- Do NOT write full code yet (unless explicitly asked later).
- Produce a build-ready implementation spec for a developer/AI builder.
- Be explicit about where each event should be fired and what properties are required.

==================================================
REQUIRED OUTPUT
==================================================

1) IMPLEMENTATION TASK LIST (BY PAGE/FEATURE)
For each page/feature:
- Events to implement
- Trigger locations
- Required properties
- Dependencies
- Priority

2) EVENT SPEC TABLE (IMPLEMENTATION READY)
For each event:
- Event name
- Trigger point (component/function/action)
- Fire timing (click / submit / success / failure / load / view)
- Debounce/anti-duplicate rules
- Required properties
- Optional properties
- Validation notes

3) CONVERSION INSTRUMENTATION PLAN
- How each conversion is detected
- How to prevent false positives
- How to link conversion to source/traffic context
- How to handle retries/errors

4) QA TEST CASES
Provide test cases for each critical event and conversion:
- Test action
- Expected event fired
- Expected properties
- Failure cases
- Duplicate-fire checks

5) POST-LAUNCH VALIDATION PLAN (FIRST 14 DAYS)
- What to monitor daily
- What anomalies to check
- What thresholds indicate broken tracking
- What to fix first if data looks wrong

Return the blueprint in a structured, implementation-ready format.

Optional Phase 4 — Code (ONLY after you approve the plan)

I keep this separate because the second you ask for code too early, AI will start guessing and you’ll get garbage instrumentation.

Here’s the starter prompt:

Use the approved analytics implementation blueprint.
Generate the tracking instrumentation code for the selected pages/events only.
Do not instrument everything at once.
Start with Phase 1 (must-have tracking).
Return:
- code changes
- file/component locations
- event names implemented
- QA steps to verify

My Recommended Naming Convention (Simple + Clean)

Keep event names generic and use properties for context.

Event name examples

• page_viewed
• cta_clicked
• form_started
• form_submitted
• form_submit_succeeded
• form_submit_failed
• signup_started
• signup_completed
• checkout_started
• payment_succeeded
• search_performed
• filter_applied

Properties (this is where the detail goes)

• page_name
• cta_name
• form_name
• plan_tier
• feature_name
• user_type
• traffic_source
• campaign
• referrer

This keeps reporting sane and avoids 300 custom events.

Practical Run Order (This is the workflow)

1. Run Prompt 1 (Audit)
2. Run Prompt 2 (Formal plan)
3. Trim the plan (remove low-value noise)
4. Run Prompt 3 (Implementation blueprint)
5. (Optional) Generate code for Phase 1 only
6. QA for 1–2 days, then roll out Phase 2

Let me know if you have any questions