Your GA4 channel-attribution report has a hole in it. Last month’s push sends show up with no medium and no source, so on paper they look like direct traffic instead of recovered revenue. You trace it to a UTM parameter that was never filled in past the placeholder your team set at install. This pushengage site settings configuration guide exists because fixing that one field today means logging into the dashboard, finding the right tab, and re-entering every other default field at once, since the form doesn’t let you edit just one.
That’s the actual cost of PushEngage site settings: not that any single setting is hard to understand, but that site details, campaign defaults, and service worker configuration live in separate places, get touched rarely enough that nobody remembers where, and take a full form re-entry to fix one field. This guide covers the three settings groups you’ll actually revisit — site details, campaign defaults, and service worker settings — and how to change any of them with a plain-language request to an AI assistant connected to the PushEngage MCP server, instead of a dashboard-tab hunt.
Why PushEngage site settings configuration turns into a support ticket instead of a five-minute fix
Site settings don’t get configured once and forgotten. They get revisited every time the business changes shape: a new market means a timezone change, a new attribution requirement means a UTM parameter update, a rebrand means the “Powered By PushEngage” toggle needs a second look, a platform migration means checking whether the service worker file still lives where PushEngage expects it. Because each of these lives in a different corner of the dashboard, the actual friction isn’t the edit itself. It’s re-finding the tab, then re-entering fields you didn’t mean to touch, on a task you’ll be doing again in three months when something else changes.
Three failure modes show up often enough to matter, and none of them throw an error when they happen:
- A UTM default gap. Campaign defaults ship with placeholder or blank UTM parameters, so every push send in that window shows up in GA4 with no medium or source, invisible in a channel-attribution report.
- A missing fallback notification. Unsegmented subscribers, the ones who don’t match any audience rule, get nothing, or generic copy, instead of a deliberate default your team chose.
- A stale service worker path after a site migration. This stops notifications from delivering at all, without producing an obvious error message pointing back to the setting that caused it.
All three just quietly cost you data, reach, or delivery until someone happens to notice, usually while looking at a report that doesn’t add up.
That’s the case for treating site settings as a recurring check rather than a one-time install step, and it’s the case for changing how you check them.
Getting started: connect the PushEngage MCP server to your assistant
@pushengage/mcp is PushEngage’s official Model Context Protocol server, and every tool in this guide runs through it. Add it to your client’s MCP config — Claude Desktop’s claude_desktop_config.json, Cursor’s ~/.cursor/mcp.json, or Claude Code’s own MCP config — with the command npx -y @pushengage/mcp. No global install is required.
The first time you ask your assistant to log you in, it opens a browser tab to authorize the connection, so your PushEngage password never touches the assistant itself, and the resulting token is stored locally on your machine. From there, ask to see your PushEngage sites and select the one you want to work on; every settings tool below defaults to whichever site you currently have selected. For the complete walkthrough, including troubleshooting connection issues, see the full PushEngage MCP setup guide.
Site details: name, URL, timezone, geolocation, and the branding toggle
pushengage_get_site_details reads your current configuration; pushengage_update_site_details changes it. Between them, they cover the fields PushEngage’s own onboarding docs call “Add Site Details”:
- Site name
- Site URL
- Timezone
- Geolocation tracking
- The “Powered By PushEngage” branding toggle on your dashboard widget
If you’ve ever needed to correct any one of those pushengage site details after the initial install, this is the tool pair that reaches all five fields, and it’s the same tool pair for reading them back before you assume something’s misconfigured.
Timezone matters more than it looks. It’s the reference point for every scheduled send and every piece of subscriber-timezone-based scheduling you run. Get it wrong and a 9 a.m. send lands at 2 a.m. for a chunk of your list, which reads as a targeting failure when the real cause is one misconfigured field.
Geolocation is off by default and has to be explicitly turned on before PushEngage can attach city, state, and country data to a subscriber record, which is the foundation geolocation targeting depends on. If your segments reference location and the numbers look thin, this is worth checking before assuming your subscriber base doesn’t have the geographic spread you expected.
The branding toggle is simpler: it controls whether “Powered By PushEngage” shows on your dashboard widget at all, which matters most for teams running a white-labeled support or chat experience where every visible vendor mark gets scrutinized.
None of these require a support ticket or a hunt through nested settings menus. The README’s own example is the pattern to follow: ask your assistant, “Change my site timezone to Asia/Kolkata and turn on geolocation,” and both fields update in one request. Correcting your site URL after a domain change, or your site name after a rebrand, follows the identical pattern.
Campaign defaults: the settings that quietly control every send’s attribution and reach
pushengage_get_campaign_defaults and pushengage_update_campaign_defaults cover four fields. These pushengage campaign defaults aren’t cosmetic. They’re the settings sitting underneath every send you run, whether or not anyone on the team remembers they exist, and getting any one of them wrong doesn’t fail loudly enough for anyone to notice right away.
- UTM parameters: your baseline for tracking push notifications with UTM parameters in GA4 or any analytics stack downstream of it. Skip this setting and every send inherits blank attribution: sends with no source or medium, unattributable revenue, a gap nobody notices until a monthly report doesn’t add up. That’s the channel-attribution report that opened this article.
- Fallback notification: what fires for a subscriber who doesn’t match any audience rule. Leave it unset and those subscribers get nothing at all.
- Fallback attributes: personalization tokens for that same unsegmented group, so their copy reads as intentional rather than broken or generic. A subscriber with no matching attribute shouldn’t see a blank space where their first name was supposed to go.
- Default notification expiry: how long an undelivered send stays queued before PushEngage drops it. A flash-sale send with a 7-day expiry can still land days after the sale ends, misleading a subscriber instead of just failing quietly, which is worse for the relationship than the send never arriving at all.
Setting a 7-day default expiry is a single request: “Set my default notification expiry to 7 days,” straight from the README’s own example. The same pattern covers a fallback notification for unmatched subscribers, fallback attributes for that group’s personalization, or a full pass at UTM parameters so every send correctly attributes back to GA4 going forward. Reviewing your current pushengage campaign defaults before a big send window, rather than after a reporting gap turns up, is the version of this habit worth building.
Service worker settings: registration, sub-folder support, and the worker file path
pushengage_get_service_worker_settings and pushengage_update_service_worker_settings cover registration, sub-folder support, and the worker file path: the mechanics that let push notifications actually reach a browser in the first place. Get any of the three wrong and the failure mode is the same. Notifications quietly stop delivering, with no obvious error pointing back to the setting that caused it, and the first symptom anyone notices is a drop in send-through numbers with no clear cause.
Sub-folder support is the one that trips up sites with platform constraints that don’t allow a root-level worker file: a CMS, a subdirectory install, a multi-site setup sharing one domain. If your worker file lives somewhere other than the root, the path setting has to match that exact location, directory and filename both, or registration silently fails.
This is the first thing worth checking after a site migration or a platform change: ask your assistant to pull your current pushengage service worker settings and confirm the registered path still matches where the file actually lives, the same kind of check PushEngage’s own service worker configuration for platform-constrained setups exists to solve.
Registration itself is worth a periodic glance too, particularly after any change to how your site loads scripts. A content security policy update, a new tag manager container, or a caching layer that strips headers can each interfere with registration in ways that show up nowhere except a quiet decline in delivered notifications. Pulling your pushengage service worker settings alongside a delivery-rate check is a five-minute habit that catches the problem before it costs you a full reporting cycle.
Partial edits without re-entering everything: why the merge behavior matters
Here’s the detail that makes asking an AI assistant faster than the dashboard, not just different: pushengage_update_campaign_defaults merges your change over the current values instead of replacing the whole record. Ask to change just the default notification expiry, and your UTM parameters, fallback notification, and fallback attributes stay exactly as they were. You don’t have to re-specify fields you have no intention of touching.
Compare that to a typical settings form, where changing one field in a saved block often means the whole form reloads with every field editable, and a slip on an unrelated field silently overwrites something that was working correctly. “Set my default notification expiry to 7 days” changes exactly one thing and leaves the rest of your campaign defaults untouched. That’s the difference between a targeted edit and a full re-save every time a single setting needs a tweak, and it’s the difference that turns a monthly settings review from a fifteen-minute chore back into the one-sentence request it should have been all along.
What accurate settings actually protect: deliverability and attribution, not just tidiness
None of this is really about tidiness. A wrong timezone breaks scheduled-send timing for part of your list. A missing UTM default breaks attribution for every send until someone catches it. A misregistered service worker breaks delivery outright, and does it silently. Each of these settings sits underneath every campaign your team runs. The campaign doesn’t fail loudly; the reporting on top of it just quietly stops matching reality.
That’s the actual case for treating site details, campaign defaults, and service worker configuration as AI assistant push notification settings you check routinely, the same way you’d check a delivery-rate dashboard, rather than a one-time setup step you configure once and never revisit. Framing these as AI assistant push notification settings rather than a buried dashboard tab means the check itself takes as long as it takes to type the request. Catching a broken UTM default or a stale worker path in one request protects the same recovered-revenue numbers your retention reporting depends on, without waiting on an IT ticket or a re-onboarding call to fix something that takes one sentence to say out loud.
Once your PushEngage MCP server is connected, run through the three settings groups covered in this pushengage site settings configuration guide the way you’d run any other retention audit: quickly, and on your own schedule, instead of only when a report doesn’t add up. It works against every PushEngage plan, including the free tier, so there’s no gate between having the MCP server connected and actually using it to check your pushengage site details, campaign defaults, and service worker settings before they cost you attribution or reach.
