What if your next campaign wrote itself?

🎯 Goal

Make company data self‑serve for PMs, design, and GTM teams.

📖 Origin Story

I was leading product decisions but kept hitting the same wall: every question needed data, and every data pull meant a long back‑and‑forth with someone who knew Metabase + schema quirks. It drained momentum. I found a blog about an engineer‑built "custom SQL GPT" for internal teams; that sparked the idea to build a product‑manager‑friendly version at PushOwl. I prototyped it during our hackathon, kept asking for feedback whenever I got stuck, and turned it into a repeatable tool with guardrails.

⚠️ Problem

Useful analysis sat behind "ask an analyst/engineer." People pasted broken SQL into Metabase; iteration cycles were slow.

🛠️ What I Built

• Schema grounding: fed GPT a clean DDL (pushowl_backend.ddl) with table purposes, relationships, and column types.
• Few‑shot library: seeded ~100 representative queries (joins, JSON operators, date filters, cohorts) + 20 curated examples.
• Value dictionaries: exported output.pdf with up to 50 sampled values per column to inform realistic filters (e.g., status IN ('enabled','suspended')).
• Error protocol: on failure, GPT asks for exact error, intent, sample rows, recent schema changes, and context; then regenerates.
• Safety rails: redacts secrets; blocks destructive ops; encourages LIMIT and EXPLAIN for expensive scans.

⚙️ How It Works

1. Read DDL + relationships.
2. Suggest SQL with comments.
3. If the user shares errors, iterate with a compact diff.
4. Offer validation steps (check row counts, edge cases).
5. Provide Metabase‑ready versions.

💡 Example Use Cases

• Campaigns using discount codes
• Data‑sync status histogram
• Logs for stores on a subdomain
• Email Omni customers who uninstalled
• Get Shopify API tokens (audited route)

📊 Impact

• Majority of ad‑hoc requests unblocked without analyst help.
• Iteration cycles faster (minutes not days).
• Better query quality via realistic value hints and error loop.

🧪 Experiments

• With vs without value dictionaries → fewer "unknown status" errors.
• Strict vs flexible error protocol → higher fix rate on first retry.
• Minimal vs guided comments → teammates ship analyses independently.

🚀 Next Steps

• Unique‑value catalog (≤30 unique → show all; else sample 100).
• Column rename plan for ambiguous fields.
• Lightweight governance ("approved joins," lineage notes).

Goal: help merchants create send‑ready HTML emails in minutes.

Problem

Most merchants stall at a blank canvas: writing copy, picking images, linking buttons, product picks, accessibility, responsive HTML.

What I built

• Goal‑aware generation: prompt captures the merchant’s outcome (launch, sale, restock, newsletter).
• Complete outputs: not just text—images (placeholders), alt‑text, CTA URLs, link structure, and responsive blocks.
• Tone/brand controls: Shopify‑merchant tuned tones + language variants.
• Product recommendations: draft related/complementary items from a product URL (heuristic today, API later).
• Customization lane: everything editable; guardrails for accessibility.

Why it’s different

• Outputs send‑ready HTML, not a copy stub.
• Works backward from the goal; proposes sections and subject lines.
• Reduces time‑to‑first‑send dramatically.

Business benefits

Top‑funnel PQLs ↑ • Activation ↑ (first campaign faster) • Retention ↑ (quality + frequency of sends) • Upsell path into higher plans

Current state (hackathon)

Working prototype; pages & help docs drafted; success metrics defined.

Blocked on

• Brevo placeholder syntax for names; dynamic product blocks from Shopify.

Experiments (type‑level)

• “One‑click send‑ready” vs “assistive editor” start → which yields more Day‑1 sends.
• Subject line variants from the same brief → open‑rate lift without over‑fitting.
• Product block variants (grid vs carousel) → click concentration vs breadth.

Impact (ranges)

• Time‑to‑first‑email: significant reduction.
• Template adoption: moved up notably among new users.
• Open/click rates: small but positive deltas in early pilots.

Next

• Domain + UI polish (PushOwl style), move Framer to org.
• Metrics pipeline (installs via UTM, adoption, success events).
• Ads/entry points in email dashboard.

Goal: suggest high‑leverage audience segments and forecast expected lift so merchants can send smarter campaigns.

Where we started

• Analyzed past campaign performance (Metabase).
• Compared competitors; mapped marketer goals; chose AI Segments as the wedge.

Scope

• Target merchants with richer data (email merchants; ≥10k customers).
• Daily three segment suggestions aligned to goals or intent (High/Medium/Low).
• Show size, recipe (formula), and estimated revenue for each segment.
• Build with Python first; plan an AI copilot layer for campaigns.

Signals & parameters (examples)

Order status, coupon use, geo, traffic source, customer type, AOV tiers, product performance, behaviors (clicked, added‑to‑cart, revisits), recency & frequency.

Predictive revenue (transparent math)

avg_order_value × expected_transactions × segment_size × conversion_probability (Shown with assumptions; never over‑claims.)

Why email first (not web push)

More data via Brevo e‑commerce; more mature practitioners; clearer ROI; fits our new launch.

Experiments (type‑level)

• Static templates vs personalized segments from store data → personalization wins.
• Daily “Top 3 segments” vs goal‑based suggestions → higher relevance.
• After a win, nudge to managed help for scaling.

Impact (ranges expected)

• Higher campaign relevance and send frequency where suggested segments are tried.
• Meaningful lift in click/conv for high‑intent cohorts.
• Upsell potential via an add‑on model.

Status

Engineering bandwidth limited in Q2; revisit with design‑first spec in Q3. Wireframe: Whimsical. Colab: data generation & scoring scripts.

Version plan

• V1: AI Copilot suggests campaigns from existing data.
• V2: Holiday/flash‑sale awareness by locale.
• V3: Intent‑aware suggestions (high vs first‑sale).
• V4: Refined segmentation rules (RAG over attributes).
• V5: Multimodal RAG for copy and image suggestions.

Goal: dynamic, personalized product blocks merchants can drop into emails/pages as a premium feature (separate from static HTML GPT outputs).

Why not bundle with HTML GPT?

HTML GPT generates static send‑ready HTML. Recommendations need to be dynamic at open/time of render, so this is a separate module.

Approach (stack‑agnostic)

• Collaborative filtering: “people like this also bought …” using interaction/purchase similarity.
• Content‑based: match on attributes (category, brand, price band, tags) for cold‑start.
• Demographic filters when available and lawful.
• Hybrid: blend store’s Shopify recommendations with our scores; fallbacks when data sparse.

Merchant value

Less manual curation, more relevant cross‑sell/upsell, better CTR/AOV.

Success signals (ranges)

Noticeable lift in click‑through on rec blocks; AOV nudges where cross‑sells appear; higher reuse of dynamic block over static grids.

Experiments (type‑level)

• 1×1 vs 2×2 vs carousel rec formats.
• “Similar items” vs “Bought together” vs “Recently viewed.”
• Price‑band constraints to avoid jarring jumps.

Next

Service spec (API), caching strategy, guardrails for availability/out‑of‑stock, and controls in editor.

Aim: auto‑produce correctly cropped/resized creatives for Android/Desktop/iOS push so merchants don’t juggle three assets.

Problem today

Users upload multiple variants or hand‑crop to fit standards; it’s slow and error‑prone.

Exploration

Tried Cloudinary’s smart‑crop via API to prove value quickly:

https://res.cloudinary.com/demo/image/upload/g_auto,c_crop,w_200,h_200/sample.jpg

Outcome

Feasible UX, but AI crop is paywalled and quality isn’t guaranteed for all product shots. After a day of POC attempts, I paused the project (cost/consistency trade‑off) and documented an alt path: simple ratio presets + safe focal‑point picker.

Success metrics (if revived)

Time saved per campaign, reduction in asset errors, satisfaction on editor flow.