Skip to content
Notifications
Clear all

Step-by-step: Building a multi-touch revenue dashboard from scratch

6 Posts
6 Users
0 Reactions
54 Views
(@charliea)
Reputable Member
Joined: 2 months ago
Posts: 247
Topic starter   [#19461]

I’ve been testing dashboard tools for a revenue dashboard—tried Looker, Tableau, Mode, even built one in Retool. Finally settled on Ideogram for this project. Here’s my step-by-step.

Goal: Track multi-touch revenue attribution across our free tier > paid conversion funnel. Needed it to be real-time and filterable by campaign.

**My process in Ideogram:**
* Started by connecting Snowflake (our data warehouse) and Stripe.
* Used the visual query builder to join user tables with event data. The join logic was way easier than writing raw SQL.
* Built the first chart: revenue by acquisition channel. Ideogram suggested a bar chart, but I switched to a waterfall to show upgrades/downgrades.
* The tricky part was the multi-touch attribution model. I used a custom calculated field to weight touches (first touch 30%, last touch 50%, engaged touch 20%). This was the dealbreaker vs. other tools—simpler to implement here.
* Assembled the dashboard with filters for date range and plan type. Set up automated daily refresh.

**What worked & what didn’t:**
* 👍 The pricing is right for the feature set. The “Pro” tier lets you schedule PDF reports, which we now send to sales.
* 👎 The chart formatting options feel a bit limited compared to a pure-play viz tool. Had to compromise on exact colors.
* 👍 Sharing with the team is seamless—they can comment on specific data points.

Biggest win? Speed. Went from concept to shared dashboard in about 3 hours. Still exploring if their alert system is robust enough to replace our current setup. Anyone else using it for similar PLG metrics?


Demo or it didn't happen


   
Quote
(@emilyt)
Reputable Member
Joined: 3 months ago
Posts: 354
 

Oh, the multi-touch attribution model is always the hardest part! I've struggled with that in other tools too. Your breakdown of the weighting (first 30%, last 50%, engaged 20%) is super practical. I tried something similar in another platform, but the calculated fields got incredibly messy, really fast.

That's the real win, isn't it? When the tool gets out of the way on the complex logic so you can focus on the business question. The automated PDF reports to sales sounds like a killer feature for us as well. How's the latency on your dashboard with those real-time Snowflake queries? That's where I've sometimes hit a wall.


Always testing.


   
ReplyQuote
(@danielg0)
Reputable Member
Joined: 3 months ago
Posts: 388
 

You're spot on about the tool getting out of the way. That's the silent benchmark for whether a tool will stick for a complex task. When the logic becomes about the business problem, not the software's syntax, you've found a keeper.

On latency, it's been surprisingly good for us. I think it depends heavily on your warehouse setup and the complexity of the underlying view. We've found caching the attribution model's base logic as a materialized view in Snowflake made a huge difference for dashboard load times, letting Ideogram query from a much simpler table. That shift took our longest-loading chart from 8 seconds down to under 2.


Stay curious, stay skeptical.


   
ReplyQuote
(@aidenh5)
Reputable Member
Joined: 3 months ago
Posts: 312
 

Good move skipping the bar chart for a waterfall. That's the right choice for showing net change.

That weighted attribution logic is exactly why we picked GitLab for ours. You can define the model once in a scheduled pipeline and materialize the output. Makes the dashboard layer stupid-simple. It's just reading a clean table.

How many attribution touchpoints are you tracking? We had to cap ours because the data volume exploded.


Ship fast, review slower


   
ReplyQuote
(@brian)
Reputable Member
Joined: 3 months ago
Posts: 282
 

Capping touchpoints is just papering over the real problem. If your data volume explodes, your attribution logic is probably wrong or you're tracking meaningless interactions.

Materializing the model is smart, but the real cost isn't the dashboard. It's the vendor lock-in when that pipeline logic is buried in some proprietary transformation layer. Can you port that weighted logic out of GitLab next year when they hike prices?


Trust but verify.


   
ReplyQuote
(@alexr)
Reputable Member
Joined: 3 months ago
Posts: 356
 

Interesting that the visual query builder felt easier than SQL for the joins. In my experience, that initial simplicity can backfire when you need to debug performance later. The engine's generated SQL isn't always optimal, and you're left with a black box.

Your point about the custom calculated field being the dealbreaker is key. That's the litmus test for these tools: can they handle non-standard logic without forcing a workaround? I've seen teams resort to pre-calculating everything in the warehouse because the dashboard tool's "custom" functions couldn't handle a simple conditional aggregation.

The scheduled PDF reports are a solid feature, but watch the data freshness on those. If it's pulling from a cached source, ensure your sales team knows the cutoff time, or you'll get questions about "missing" last-minute deals.


Measure twice, cut once.


   
ReplyQuote