A HubSpot portal full of fresh leads feels like momentum. Then, two weeks later, you pull up the timeline for a handful of them and it is quiet. A form fill, one pricing-page view, maybe an email open. Then nothing.
That gap is exactly where push notifications on web shine. Not as a replacement for email, but as the nudge that keeps the conversation alive when inboxes are crowded and follow-ups slip behind other priorities.
In this guide, I will walk you through the same core strategy as the original article. You will map a drip journey, build HubSpot lists and workflows, and trigger browser and mobile pushes through a delivery layer. The difference is that we will treat the delivery layer like a modern engineering component. Observable, secure, and swappable. That is where SashiDo. Push Notification Platform fits in for teams that need speed without giving up control.
Along the way, I will give you a ready-to-use 7-message framework with copy examples, a practical webhook setup approach, reporting KPIs, and a troubleshooting playbook for the real-world stuff that breaks at 4:45 pm.
Why drip push beats drip email when leads go quiet
A few quarters ago I watched a Growth and Retention CRM Manager at a 120-person SaaS company do the usual post-webinar follow-up. The email sequence was fine. Helpful content, customer story, soft demo invite. The problem was not the messaging. The problem was the channel.
Even with good subject lines, their webinar leads were sitting inside packed inboxes. The team could not iterate fast either, because every small change needed a developer to update templates, UTM logic, or event wiring.
They added a simple drip sequence using a push web notification as the fast lane. The pattern was straightforward: when a lead consumed something high-intent, like a pricing page or implementation doc, the next touch happened via a notification that appeared on-screen within minutes, not days.
The first major insight is this. Push works best when it is tied to a moment the lead already cares about, and when your cadence is predictable enough to build trust.
Quick test: Send your first HubSpot-triggered push with SashiDo - Push Notification Platform in under 10 minutes.
If you take only one thing from this article, take that. You will get more lift from a clean trigger and a sane cadence than from rewriting copy for the tenth time.
The strategic foundation: map your drip journey before you touch HubSpot
When teams struggle with lead nurturing, it is rarely because the workflow tool is missing a feature. It is because the sequence was never mapped to a real decision journey.
Instead of starting in HubSpot, start with a one-page campaign map with three columns: Stage, Message goal, Next step. You are not planning content. You are planning momentum.
A typical B2B journey you can model in an afternoon looks like this: the lead signs up, tries to self-educate, compares options, worries about implementation effort, and then either books a call or disappears.
Now take that journey and decide what you want each push to accomplish. Early notifications should feel like a helpful guide. Later notifications can carry proof and a gentle offer.
Pick 5 to 7 topics that naturally lead to your solution
For a Growth and Retention CRM Manager, the most effective drip topics tend to cluster around friction. Things that reduce perceived risk and speed up time-to-value.
For example, if you are nurturing leads for a SaaS product, your 5 to 7 topics might be: getting started in 15 minutes, integrating with the tools they already use, how your data model works, what security looks like, how teams measure success, and what happens after the trial.
Those topics become your push cadence. You are not sending “news”. You are answering the next question the lead would ask if you were in the room.
Choose a cadence that avoids fatigue and still feels alive
The source article’s timing guidance is a solid baseline. For most teams, this cadence works well as a starting point:
- Immediately: welcome and set expectations
- Day 1: quick win, tangible value
- Day 3: education that reduces confusion
- Day 7: social proof
- Day 14: soft pitch
- Day 21: objection handling
- Day 30+: ongoing value or reactivation
The trade-off is simple. More frequent messaging can lift short-term clicks, but it increases opt-outs. Less frequent messaging keeps opt-outs low, but your leads cool off.
A practical rule I use. If your notifications are teaching something, you can be more frequent. If they are asking for something, slow down.
HubSpot setup: lists, properties, and enrollment triggers that do not bite later
Good lead nurturing in HubSpot is mostly about choosing the right inputs. Your workflows will only be as smart as your segmentation.
Step 1: create the minimum contact properties you will actually use
Start with properties you can reliably populate and explain to your future self:
- push_opt_in (true or false)
- push_platform (web, android, ios)
- push_provider (optional. if you are migrating, this helps track cohorts)
- nurture_track (for example: webinar, content, trial)
- last_push_sent_at (helps with frequency caps)
If you already collect mobile device tokens through your app, tie the lifecycle events you already trust into HubSpot. Do not build a parallel truth.
Step 2: build active lists that reflect intent, not just demographics
Go to Contacts, Lists, and create Active lists that update automatically. Keep it small at first.
A practical starter set for drip pushes looks like this:
- New Push Subscribers (30 days): push_opt_in is true, create date is within 30 days
- High Intent: visited pricing page or requested demo or viewed implementation docs
- Dormant: no email opens and no site activity in 30 days, but push_opt_in is true
- Engaged: clicked any push in last 14 days
This structure lets you do the two things that actually matter. Start a welcome drip for new subscribers, and branch into different tracks based on real behavior.
Step 3: pick enrollment triggers that prevent duplicates
Duplicate notifications are a common “we hate push” moment for users. In HubSpot, duplicates usually happen because a contact is enrolled in multiple workflows, or because a trigger re-fires without a guard.
Use one of these patterns:
- Trigger on a property change, like push_opt_in becomes true, then set a “welcome_started_at” property as a guard.
- Trigger on list membership, but add a condition step that checks last_push_sent_at and exits if it is too recent.
HubSpot’s webhook action is documented here, and it is worth skimming before you build. It clarifies what gets sent and how to debug failures.
External reference: HubSpot workflow webhooks documentation: https://knowledge.hubspot.com/workflows/customize-webhooks
Turn workflows into drip pushes: HubSpot as the brain, SashiDo as the delivery layer
The original article frames HubSpot as the automation brain and a push provider as the delivery engine. That model is still the cleanest way to think about it.
Your CRM team owns segmentation, timing, and message logic in HubSpot. Your delivery layer owns routing, platform-specific delivery, and the operational stuff you need at scale, like retries and observability.
This is where a scalable push notification backend matters. Your drip is not one campaign. It becomes a system. When you start running onboarding, product education, renewal nudges, and win-back flows, you need the same reliability you expect from email infrastructure.
A simple webhook architecture you can ship without heavy engineering
At a high level, HubSpot triggers a webhook when a contact hits a workflow action. That webhook calls your push delivery endpoint. The delivery layer then sends to web browsers, Android, and iOS depending on the tokens you have.
If you are swapping providers, keep the contract stable. Your HubSpot workflow should emit a payload that is provider-agnostic. Then the delivery layer translates it.
A payload that tends to age well includes:
- contact_id
- external_user_id (your app user id if you have one)
- audience_tags (like nurture_track or segment)
- platform (web, android, ios)
- title
- body
- url (for push notifications on web, this matters)
- campaign_id and step_number
You can also include personalization tokens resolved in HubSpot, like first name or company name. Keep it sparse. Too much personalization increases failure modes.
Migration note: swapping out PushEngage as the delivery layer
If you are currently using a tool like PushEngage to deliver browser notifications, treat the migration like any other infrastructure change. Run both in parallel for a short period, and move cohorts, not everyone at once.
Here is the pragmatic migration flow I recommend:
- Create a “new delivery layer” workflow in HubSpot that targets a small internal test list.
- Send the same message through the new path and verify delivery, opens, and click attribution.
- Move one nurture track first, like the welcome series. Keep your other campaigns on the old provider until you trust reporting.
- Add frequency capping to avoid double-sends during overlap.
The win is not just feature parity. The win is speed. When the CRM Manager can change sequencing in HubSpot without waiting on engineering, your nurture program starts compounding.
Where SashiDo fits for developer-first teams
SashiDo - Push Notification Platform is useful in this exact middle ground. Your CRM team wants control and iteration speed. Your engineering team wants a delivery layer that behaves like infrastructure, with clear knobs and visibility.
When you are dealing with web plus mobile, it also helps to have one delivery mindset across platforms. The way you measure and debug web push is not identical to the way you debug push notifications android or an ios push notification, but your reporting goals are the same.
External references that help frame platform behavior:
- MDN overview of the Push API for web push fundamentals: https://developer.mozilla.org/en-US/docs/Web/API/Push_API
- Apple APNs connection overview for iOS delivery context: https://developer.apple.com/documentation/usernotifications/establishing-a-connection-to-apns
The 7-message drip framework (with copy you can paste today)
The most reliable nurture framework I have used mirrors the original article’s structure. It is simple enough to execute and flexible enough to personalize.
Below is a 7-step drip you can run across push notifications on web and mobile. The copy is intentionally short because the best push notifications read like a tap on the shoulder, not a mini email.
Message 1: immediate welcome
Goal: confirm subscription and set expectations.
Example:
Title: Welcome. Your quick wins start here
Body: You will get 1 to 2 tips a week. First one. Save this checklist for later.
Message 2: day 1 value delivery
Goal: deliver a tangible win with no ask.
Title: The 10-minute setup most teams skip
Body: Do this once. It makes every future campaign easier.
Message 3: day 3 education
Goal: reduce confusion with one concrete lesson.
Title: Segmenting in HubSpot, the simple way
Body: New subscribers, high intent, dormant. Start there.
Message 4: day 7 social proof
Goal: show that peers succeed with the approach.
Title: How teams keep leads warm without more emails
Body: A quick story. One workflow, 7 touches, steady lift.
Message 5: day 14 soft pitch
Goal: introduce your solution as the next logical step.
Title: Ready to automate this from HubSpot?
Body: Here is the workflow you can clone and tweak.
Message 6: day 21 objection handling
Goal: address the most common hesitation.
Title: Worried about fatigue and opt-outs?
Body: Add a frequency cap and a preference link. You are safe.
Message 7: day 30 follow-up or reactivation
Goal: keep the relationship alive or win back.
Title: Still working on this?
Body: Here is the fastest path to results. No rebuild needed.
If you want to go one step further without making the program fragile, A/B test only the title for each step first. Then test timing. Changing copy, targeting, and cadence all at once makes your data meaningless.
Practical HubSpot workflow build: a welcome drip you can launch in one afternoon
Let’s turn the framework into a HubSpot workflow that actually runs.
Step 1: enrollment trigger
Create a contact-based workflow called “Push Welcome Drip”. Enroll when push_opt_in becomes true, and optionally when nurture_track equals a specific source like webinar or content.
Add a guard. If welcome_started_at is known, do not re-enroll.
Step 2: action sequence with delays
Use the same cadence every time you test a new message sequence. That is how you learn.
A clean starting sequence is:
- Action 1: webhook send, message 1, no delay
- Delay: 1 day
- Action 2: webhook send, message 2
- Delay: 2 days
- Action 3: webhook send, message 3
- Delay: 4 days
- Action 4: webhook send, message 4
- Delay: 7 days
- Action 5: webhook send, message 5
You can extend to 7 messages once you confirm delivery and baseline engagement.
Step 3: personalization tokens that do not break reporting
Use one or two tokens max, like first name and company. If those properties are missing too often, you will end up with awkward messages or failed payloads.
Good rule. If a token is missing for more than 10 percent of your contacts, do not use it in push.
Measuring what matters: delivery, opens, clicks, conversions, opt-outs
If your CRM Manager persona cares about anything, it is whether the channel is helping reduce churn and increase lifetime value. Push is measurable. You just need the right baseline.
The KPI set I recommend for drip pushes
Track these as a weekly dashboard, then slice by segment and by step number in the drip:
- Delivery rate (technical health)
- Open rate (creative and timing)
- Click-through rate (message relevance)
- Conversion rate (landing page and offer)
- Opt-out or unsubscribe rate (fatigue signal)
The benchmarks in the source article are reasonable as directional targets. In practice, your “good” number depends on whether the message is educational or promotional. Step 1 and 2 should outperform step 5 and 6.
How to set this up in HubSpot without overbuilding
Use a simple pattern:
- Store campaign_id and step_number in the webhook payload.
- When your delivery layer reports back events like delivered, opened, clicked, update a HubSpot custom event or a contact property rollup.
- Build a report grouped by campaign_id and step_number, then add filters by segment.
This gives you enough clarity to answer the questions you actually have, like which step causes opt-outs, or which segment responds to education versus offers.
Push notification delivery monitoring is not optional at scale
Once you send beyond a few thousand notifications a week, you need push notification delivery monitoring. Not for vanity metrics, but for operational confidence.
If delivery drops, it might be permission churn, expired tokens, misconfigured VAPID keys for web push, or mobile token invalidation. The point is not to guess. The point is to see failures quickly and isolate whether the issue is your workflow, your payload, or the platform.
A/B testing: keep it boring, keep it fast
Most teams make A/B testing too complicated. You do not need five variants. You need one question per test.
Start with titles because they dominate opens. For example, test curiosity versus direct value:
- Curiosity: The one HubSpot setting that saves your drip
- Direct value: Fix your workflow enrollment in 5 minutes
Then test timing. B2B leads often respond during business hours. But do not assume. Your product might be used at night.
Finally, test the landing page linked in the notification. A great push that lands on a generic homepage wastes the click.
Troubleshooting: the stuff that breaks and how to fix it
This section is here because real teams run into real failures. When you are pushing from HubSpot through webhooks, “it should work” is not enough.
If HubSpot says the webhook fired, but no one received a notification
Start with the workflow history. Confirm the webhook action succeeded. If it failed, HubSpot will show an error response.
If it succeeded, the next question is whether the delivery layer had valid tokens for the user. On web push, tokens are tied to browser permissions. On mobile, tokens can rotate.
Use a test contact and verify they have an active subscription on the device you are testing.
If you see firebase push notification issues on Android
On Android, a large share of delivery problems come from token handling and app state. Firebase has a solid troubleshooting page that is worth bookmarking.
External reference: FCM troubleshooting documentation: https://firebase.google.com/docs/cloud-messaging/troubleshooting
If you are seeing drops, confirm your app is correctly handling token refresh events, and confirm your network environment is not blocking FCM connectivity. Debugging becomes much faster when you can correlate “HubSpot triggered” with “provider accepted” with “device received”.
If web permission prompts are killing opt-in rates
This is more common than most marketing teams realize. Chrome introduced a quieter permission UI for sites with low acceptance rates or for users who often deny prompts. If your opt-in prompt is poorly timed, you can be silently pushed into a less visible permission experience.
External reference: Chrome quieter permission UI background: https://blog.chromium.org/2020/01/introducing-quieter-permission-ui-for.html
Practical fix. Do not ask for permission on page load. Ask after a value moment, like after a signup, a saved preference, or a completed download.
If you are fighting push notification debugging in production
This is the checklist I use to avoid hours of guessing:
- Validate the workflow trigger and enrollment criteria. Most “random” sends are actually duplicate enrollments.
- Inspect the webhook payload. Missing user identifiers or malformed URLs cause silent failures.
- Confirm platform routing. Web, Android, and iOS require different delivery assumptions.
- Watch error codes and token invalidation. Treat invalid tokens like bounced emails. Remove them.
- Compare provider logs to HubSpot workflow logs to isolate where the failure starts.
If you make one operational improvement, make it this. Assign every notification a campaign_id and message_id so you can trace it end-to-end.
Web push, Android push, iOS push: one strategy, different constraints
Your drip strategy can be consistent across platforms, but the constraints differ.
With push notifications on web, you are fighting browser permission UX, device switching, and notification overload. With push notifications android, you are often fighting OEM background restrictions and token refresh. With an ios push notification, you are fighting user sensitivity to interruptions and strict platform rules.
The point is not to treat them like separate programs. The point is to keep your nurture logic in HubSpot, then let your delivery layer handle platform-specific details and monitoring.
If you are evaluating vendors, it is also worth seeing how they think about platform coverage and control. For example, teams that compare OneSignal and SashiDo often focus on how much they can customize delivery and data handling.
External reference: SashiDo vs OneSignal comparison page: https://www.sashido.io/en/sashido-vs-onesignal
A simple “ship it” checklist for your first HubSpot drip push
You do not need perfection to launch. You need correctness and observability.
- Confirm you have a push_opt_in property and it is reliably populated.
- Build one Active list for new subscribers and one for high-intent visitors.
- Launch a 3-message drip first, then extend to 7.
- Add frequency caps using last_push_sent_at to prevent fatigue.
- Track delivery, open, click, conversion, and opt-out per step.
- Keep a rollback plan. Disable one workflow, not five.
When you run this for two weeks, you will have enough data to decide whether to expand segmentation, add behavioral triggers, or build a re-engagement series for dormant leads.
Conclusion: make push notifications on web a dependable part of your HubSpot nurture engine
If you are responsible for growth and retention, your biggest enemy is not a lack of ideas. It is the time between idea and launch, and the blind spots when something breaks.
A well-mapped drip sequence, implemented as HubSpot workflows that trigger browser and mobile notifications, gives you a channel that is immediate, measurable, and easy to iterate. Done right, push notifications on web become the connective tissue between your content, your product, and the moment a lead is ready to take the next step.
Ready to replace PushEngage with a developer-first, enterprise-grade delivery layer? Migrate to SashiDo - Push Notification Platform to get unified push, advanced segmentation, real-time delivery, and enterprise security. Start here: https://www.sashido.io/en/products/push-notifications-platform
