What Bounce Rate to Set on a Traffic Campaign

Set it near the bounce rate your own organic sessions already produce on the exact pages you are sending traffic to. That is the whole rule. Three things follow from it, and they cover almost every campaign:

1. Copy your own property, not a benchmark. Published bounce rate averages come from other people's sites, with other people's tag configurations. Yours is the only comparable number you have.
2. Zero percent is not a good score, it is a fingerprint. A campaign that never bounces creates a step change in your site total that anyone reading a month over month report will see immediately.
3. The number you set is not the number you will read. Traffic products define a bounce the way Universal Analytics did, as a single-page session. GA4 does not. Set 70% and watch GA4 report something far lower, with nothing broken anywhere.

That third point is the one almost nobody plans for, so it gets its own section.

Before picking a value, know which dial exists on which product, because they are not the same dial.

Two details in that table decide how you should think about the setting at all.

It is a population ratio, not a property of a visit. A single session either gets one URL or it gets more than one. Setting 40% does not make each visit forty percent bouncy. It means roughly four sessions in ten are given one URL and the rest are given two or three. The setting therefore has coarse resolution by nature, and asking for 63% rather than 65% is asking for a rounding difference in a session mix.

On SERP Clicks and on Sparky there is no percentage at all. SparkCliks says this plainly in its own SERP Clicks FAQ: analytics counts a bounce as any single-page session, so a clicker who visits one page and leaves is recorded as a bounce, and adding a second URL at no extra cost removes it. That dial is binary at the order level. On Sparky you are writing the flow yourself, so the bounce rate is whatever your script produces, which makes varying it your job rather than the platform's.

The neighboring settings live in visit duration and pages per session, and they are not independent of this one. Pick a bounce rate and you have partly picked a page count.

Here is the part that surprises people on day three of a campaign.

Traffic products define a bounce as a single-page session. That is the Universal Analytics rule, and Universal Analytics stopped processing data for standard properties on 1 July 2023. GA4 replaced the rule outright. In GA4, bounce rate is the exact arithmetic inverse of engagement rate: the share of sessions that were not engaged. A session counts as engaged if it lasts longer than 10 seconds, or reaches two or more pages, or fires a key event. Google documents this in Engagement rate and bounce rate in GA4.

Three escape routes, and a traffic campaign trips one of them constantly.

Read the second row twice. Set visit time to two minutes and bounce rate to 70%, and every one of those single-URL sessions clears the 10 second engagement threshold, so GA4 files them as engaged sessions. The campaign delivered a 70% bounce rate by its own definition and your report shows almost none of it. Nothing failed. Two systems counted different things using the same word.

The last row is the only lever on your side. The engaged session timer is configurable, and as documented on the page linked above it accepts values from 10 to 60 seconds. You reach it in GA4 under Admin, then Data streams, then your web stream, then Configure tag settings, then Adjust session timeout. Google rearranges that interface regularly, so search the setting name rather than trusting the path. Raising the timer raises your bounce rate everywhere, including on organic traffic you never touched, which is usually a worse trade than accepting the campaign figure.

One wrinkle is specific to the standard Website Traffic engine: it loads the page and waits. No scroll, no pointer movement, no click. It fires no key events of its own, so that escape route stays closed unless your site fires something automatically on load. Realistic Traffic does click a link, and an internal link click is a second pageview, which closes the bounce through the page count route instead. The difference between the two engines shows up in your reports here more sharply than anywhere else.

The setting goes down to 0%, and buying a campaign that never bounces is the most common mistake in this product category.

Start with the arithmetic, which is more convincing than the argument. Your reported site bounce rate is a weighted average of everything in the property. Drop a block of never-bouncing sessions into it and the total moves by an amount anybody can see. Illustrative figures, with an existing site bounce rate of 60%:

Only one row leaves the reported number where it was, and it is the row where the campaign setting equals what the site already does. Every other cell is a discontinuity on a specific date. A 30 point drop on the Tuesday a campaign started is not subtle, and it is precisely the pattern an agency, a buyer or a new analytics hire looks for first. The rest of that audit trail is in how to spot bought traffic in analytics, and the bounce rate step is usually the opening exhibit.

There is a second reason to stay off the floor. Any GA4 property reporting under roughly 5% bounce rate deserves a tag audit before it deserves congratulations, because duplicate pageview tags and stray interaction events produce exactly that reading. Engineer a number that low and you have made your own property look misconfigured, so the first person to investigate starts pulling on your tag instead of believing your traffic.

The useful framing: you are not trying to win the bounce rate. You are trying to keep it boring.

The other half of picking a value is accepting that there is no single site-wide answer, because pages have different jobs and a bounce means something different on each one.

This is where campaign settings usually go wrong. Someone sends traffic to a set of blog posts, decides that 20% looks healthy, and sets 20%. The result is a set of article URLs where four visitors in five click deeper into the site, which is not how anybody reads a blog post. The number looks fine in isolation and looks strange the moment it sits next to the same pages' organic behavior.

A contact page at 15% is a stranger claim still. Unless the phone tap and the form submit are registered as key events, a contact page visit that succeeds is a single-page session, and a single-page session is a bounce.

Match the setting to the destination URLs, not to the site. If the campaign points at three article URLs, the reference number is the median bounce rate of your articles, not your site average, which is dragged down by your homepage and your category pages.

Fifteen minutes in GA4 gives you a defensible number. All figures below are illustrative, not SparkCliks data.

Step 1: check the configuration before reading anything. Two questions invalidate most bounce rate conclusions. Does the property have key events configured at all? If not, one of GA4's three engagement routes is switched off and your bounce rate is structurally high. Is the engaged session timer at the 10 second default? If somebody raised it, write down the value, because every number below shifts with it.

Step 2: pull the landing page baseline. Open Explore and start a blank Free form exploration. Dimension: Landing page plus query string. Metrics: Sessions, Bounce rate, Engagement rate, Average engagement time per session, Key events. Filter where Session default channel group exactly matches Organic Search. Date range: last 28 days, or last 90 days if any single page falls below a few hundred sessions.

Step 3: cut the thin rows. Keep only landing pages with at least 300 organic sessions in the window. Below that, one unusual afternoon moves the percentage several points and you will be reading weather as climate.

Step 4: group by page type and take the median. Articles in one group, product and service pages in another, hubs in a third. Take the median inside each group rather than the mean, because two outlier URLs should not set your campaign policy. The median for the group your destination URLs belong to is your target.

Step 5: cross-check against Search Console. For the same URLs, open Performance, then Search results, switch to the Pages tab, set the same 28 days, and export clicks, impressions, CTR and average position. You are looking for destination pages that already receive search clicks, because those are the pages where an odd bounce rate is most likely to be noticed and least likely to be explainable.

Step 6: sanity check the ceiling. Look at average engagement time per session for the destination pages. If your articles hold readers for 90 seconds, a campaign visit of 20 seconds is a mismatch in the other direction, and it pairs badly with a high bounce rate setting.

Example output from a realistic-looking property, for illustration only:

If the campaign points at articles, the target is 74%. Not the site average, and not a published benchmark from somebody else's property.

Take the median from step 4 and land in its neighborhood rather than exactly on it. Sitting on the identical round number every week is its own small tell.

Then run a before and after design so the result can be read rather than guessed. Baseline: 28 days before the campaign, organic segment only. Control set: 8 to 12 pages of the same type and roughly the same session volume that you deliberately do not send traffic to. Change window: 28 days from the day the campaign starts, with the first 7 days treated as settling rather than as data. Read the movement in the campaign pages against the movement in the control pages, never against zero, because seasonality moves both sets together.

On signal size, illustrative numbers again: a page with 400 sessions at a 74% bounce rate produces 296 bounced sessions, and moving it to 70% produces 280. A gap of 16 sessions sits inside ordinary week to week variation. Under roughly 1,000 sessions per page per window, pool your pages and treat any single page's result as directional only.

Seven days in, pull the campaign segment and your organic segment side by side and compare two columns: bounce rate and average engagement time per session. Then reconcile them against the definition gap.

The trade-off is structural rather than a vendor limitation: under GA4 rules a single-page session cannot both last a long time and count as a bounce. Decide which of the two numbers your report actually needs. In most cases the honest answer is that neither is worth engineering, and the setting exists so that delivered traffic does not distort a dashboard you rely on for real decisions.

If the campaign segment reports a much lower bounce rate than you configured, that is the timer, not a delivery failure. Accept it, shorten the visit time, or stop reporting bounce rate and report engagement rate instead, since in GA4 the two are the same number printed twice.

It does not touch search rankings. Bounce rate is not a ranking factor. It is computed inside your analytics property from hits your own tag sends, and a ranking system has no access to it. The clearest evidence is that Search Console, the reporting tool a search engine provides for your own site, has no bounce rate metric at all: it reports clicks, impressions, CTR and average position. The full argument, including what a search engine genuinely can observe from its own side, is in why bounce rate is not a ranking factor, and SparkCliks states the same thing in its own product FAQ.

So if the motive for setting a favorable bounce rate is to look good to a search engine, the setting cannot do it, because the search engine never sees the number. Anyone selling a bounce rate dial as an SEO lever is selling a reporting cosmetic.

Two other things it does not do. It does not create conversions, and a campaign segment that starts producing form fills or purchases is a measurement fault worth investigating rather than a result. And it does not make automated traffic safe for an ad-funded page: automated visits counted as ad impressions are invalid traffic under every major ad network's rules, and the penalty lands on the site owner's account rather than the vendor's. If the destination pages carry ads, that risk is yours, and when not to buy website traffic is worth reading before you configure anything at all.

What the setting does do is keep delivered traffic from rewriting a report you use to make decisions. That is a small, real benefit, and it is the entire case for choosing the value carefully.

Run these in order. The first three decide whether the rest are meaningful.

1. Do you have at least 28 days of organic analytics history on the exact destination URLs? If not, get the baseline before running anything.
2. Are key events configured in the property, and is the engaged session timer at the 10 second default? Note both before comparing any figure with anything.
3. Have you taken the median for the destination page type rather than the site average?
4. Is your chosen setting inside your own measured range, and off the round number that repeats every week?
5. Do you know what share of total sessions the campaign will be? At half your sessions, any gap between the setting and your baseline lands in the site total at full strength.
6. Is the visit time above or below the 10 second engagement threshold, and do you know which reported number that produces?
7. Have you held a control set of pages you deliberately do not send traffic to?
8. Do the destination pages carry ads? If so, reconsider the campaign rather than the setting.
9. Are you reporting bounce rate and engagement rate in the same dashboard? In GA4 that is one number twice.

The reframe is small and it saves a lot of arguing. Stop asking what bounce rate makes the campaign look good, and start asking what bounce rate makes the campaign look like nothing happened. That question has an answer, and it is sitting in your own Explore report.