Tracking Who Views Your Pitch Deck

Problem

After talking to my founder friend Yash, he mentioned that he has analytics on his product which helps him improve his product marketing data to improve their marketing campaigns.

But there isn't a tool for him to make informed decisions for his pitch deck.

He shares the deck and it goes into the void. There are no signals or insights that can help him improve his deck before sharing it with other investors.

Product Thinking

This is the lens I had before starting to think about the product...

So this raises the question, what can that founder decode from just looking at their interactions.

There are three things:

1. How much time did they spend reading?
2. Which page did they spend the most time on?
3. How much of the deck did they actually read?

This will help the founder identify which parts of their deck are working and which are not, so they can update it for the next investors.

Mini Product Spec

• Upload PDF - 5MB limit
• Auto-generate unique links
• Versioning - new PDFs generate new links and have separate tracking
• Password protected links (optional)
• Require email to view (optional)
• Track user activities - Ignore the first and last pages from overall metrics and account for inactive state of browser tabs
• Metrics split by Sessions, Pages and People
• Ability to exclude internal users

Branding

The goal of share-your-deck.com is to replace uncertainty with clarity, and every deck shared is an opportunity in motion.

These were the two pillars on which the whole branding is based:

1. Opportunity

2. Visibility

So they also became the root of our logo.

Using the familiar hexagonal "sale" shape to symbolize opportunities to save and discover value, and using the eyes to represent vision, we built our logo.

Together, the eyes and the radiant form tell a complete story of active visibility.

The deck isn't just sent. It's seen, tracked, and understood in real time.

This also becomes the mascot for the brand.

Building the App

Tech stack for this product is Angular and NodeJS on top of GCP. The reason is that I have seen these in production every day at my job at Velt.dev so I know it can scale and provide good devex as well.

The full development of this app was done alongside Cursor to speed up the go-to-live process.

It took me 2 weeks of work to make everything.

Server Architecture

• Serverless from the jump — no Node layer. Browser talks straight to Firebase via SDK; auth, rules, and indexes are the whole "backend."
• Two databases, picked on purpose:
  • Realtime DB for chatty viewer writes (5s push cadence)
  • Firestore for owner metadata. Each tool plays to its strength.
• Anonymous writes by design — database.rules.json has the eyebrow-raising "auth == null || auth != null" (i.e. always true) on sessions/. Viewers aren't logged in; the fileId in the path is the access control.
• Public-read workspaces — anyone can read workspaces/* (so /{slug} works without auth); only the owner email on the token can write.
• Storage is just a CDN for PDFs — no resizing, no signing dance. URL lives on the workspace doc.
• fileSummaries as a tombstone — on delete, aggregates are computed once and parked in Firestore so analytics outlive the source PDF.

Frontend

• Angular standalone SPA where services are providedIn: 'root'.
• PdfAnalyticsService is the heart of tracking.
• We have three timers (1s UI, 5s sync, 5s inactivity), activity listeners that pause the clock so idle time doesn't inflate "time on page."
• Batched writes, not chatty so the page changes pool and flush every 5s. Arrow-key users hit the DB the same as slow readers.
• LocalStorage as a session lifeline. Keyed pdf_session_{filename}_{email} with 24h TTL.
• Cache service in front of every aggregate. Toggling the domain filter busts the cache via an RxJS filterChanged$ subject; components re-render without a refetch.
• Median, not mean. One tab left open overnight stops being a metric-killer.
• ngx-extended-pdf-viewer does the PDF lift — the app only owns the analytics overlay and the page-change hook.

Deployment

• Firebase, one command — `firebase deploy` ships hosting, rules, and indexes in a single shot. No CI/CD pipeline.
• Static SPA on the CDN — Angular builds to `dist/`, Firebase Hosting serves it globally with SPA rewrites.
• Two environments, one repo — dev and prod swap Firebase projects at build time via Angular's `fileReplacements`.
• Rules live in git — Firestore, RTDB, and Storage rules ship from the repo, not console clicks.

Implementing Feedback

With each iteration, I got feedback from my friend and I kept improving the product.

Here are some things that I added after the feedback:

• Ability to have a constant URL even after the PDF is updated so everyone has the latest deck
• Sorting page-level data by who viewed first or by latest view
• Filtering internal email IDs from the data
• Additional metrics like average time and longest session time

Current Situation

The app currently has 3 users since I haven't invested time in marketing as I have been just building it so far.