Desktop, Mobile or Mixed: Picking a Device Split

Mirror what you already have. Three rules cover almost every campaign.

1. Measure before you choose. Pull the device breakdown for the pages you are about to send traffic to, from the last 28 days of organic sessions. That percentage is your setting.
2. Weight by the URLs in the campaign, not by the site. A site that is 62 percent mobile overall can have a docs section that is 80 percent desktop. If the campaign only touches the docs, the site number is the wrong number.
3. Skew only for a reason you can write down. Testing a rebuilt mobile template is a reason. Believing that one device counts for more is not, because no search engine reads your analytics.

Everything below is how to get those three right, plus the one confusion that sends people to the wrong setting entirely.

A device setting picks which user agent and screen size pool each session is drawn from. It is a browser profile, not a physical handset, and that is exactly why it lands in your reports: analytics platforms classify device category from the user agent string and the viewport, so what you configure is what gets counted.

The options differ by product, and one of those differences is a hard constraint rather than a preference.

The SERP Clicks limitation is worth saying out loud, because most vendor pages would bury it. If your organic audience is mostly phones, that desktop clicker pool cannot reproduce its shape, and the products that can are Website Traffic and Realistic Traffic, where device is a per-campaign control.

Device also sits alongside the other realism settings rather than above them, and they all have to agree. A session carrying a mobile user agent, a desktop-only referrer path and a country your site has never served is three mismatches stacked in one row of your data.

This is where most advice on this topic goes wrong, and getting it right saves you from choosing a setting for a reason that does not exist.

Mobile-first indexing describes how Google fetches and renders your pages for its index. Google Search Central's documentation is explicit that crawling happens with the smartphone Googlebot, a transition completed for the remaining sites on 5 July 2024. The subject of that sentence is a crawler. It is about which version of your HTML gets parsed, whether your mobile template hides content the desktop one shows, and whether your pages render properly at a phone viewport.

It says nothing about which devices your human visitors use.

The two ideas share the word "mobile" and almost nothing else:

Sending mobile-profile traffic does not make your site more mobile-first indexed and does not signal anything to an indexing pipeline. Crawlers do not read your analytics property, and neither does the ranking system: search engines have been consistent that behavioral data of this kind is not a direct ranking factor.

So treat the device split as a data hygiene decision, not an SEO lever. You are choosing whether the traffic you buy blends into your reporting or contradicts it.

Before touching a campaign setting, spend ten minutes here. The path matters, because the number you want is organic sessions on specific pages, not the property total.

Step 1. Open the tech report. In Google Analytics 4, go to Reports, then User, then Tech, then Tech details. Set the dropdown above the table to Device category. You now have desktop, mobile and tablet rows with session counts.

Step 2. Fix the date range. Use the last 28 days, ending three days before today. The trailing days are still settling, and a partial final day drags whichever device peaks in the morning. If the site is seasonal, compare against the same 28 days a year earlier.

Step 3. Filter to organic search. Add a comparison or filter on Session primary channel group set to Organic Search. Paid, email and social each carry their own device skew, and blending them gives you a number that describes your marketing mix rather than your search audience.

Step 4. Narrow to the campaign pages. If the campaign points at three URLs, build a free-form exploration instead: rows Device category, a second dimension of Landing page + query string, metric Sessions, filtered to those paths. This is the step almost everyone skips, and it is the one that changes the answer.

An example result. The figures below are an illustration, not SparkCliks data:

Read two things off that table. The split itself, roughly 64 / 31 / 5, is your target mix. The engagement rate column is the sanity check: desktop engaging nine points above mobile is ordinary for a content site, and if your numbers show mobile engaging far better than desktop, examine your measurement before you trust the split. Note the tablet row too. Five percent is normal, and it is the number a careless setting destroys, which is section seven's problem.

GA4 tells you who arrived and got measured. Search Console tells you who searched and clicked. Comparing them takes two minutes and catches a class of error that would otherwise get baked straight into your campaign.

Open Search Console, go to Performance, then Search results, then the Devices tab. Set the date range to the last 28 days so it matches what you just pulled from GA4. Add a Page filter for the URLs in the campaign. Read the click share by device rather than the impression share: impressions tell you where you appear, clicks tell you who actually came.

Here is the part competing guides leave out. On the same pages over the same window, those two device splits should agree within a few points. When they do not, the gap is diagnostic.

If Search Console reports 70 percent of clicks from mobile and GA4 reports 47 percent of organic sessions from mobile, you have not found two audiences. You have found roughly a third of your mobile arrivals disappearing before your tag fires. The usual causes are a consent banner that mobile users dismiss by leaving, a tag that loads after a slow largest contentful paint on a phone connection, or an interstitial that eats the session. Fix that first. Copy the broken number into a campaign and you will spend money reproducing your own blind spot, then congratulate yourself when the reports agree.

For the Search Console side in more depth, the organic CTR measurement walkthrough covers the filters, comparison windows and export steps in detail.

There is no industry benchmark worth copying here, because device share is driven by what the person is trying to do at the moment they search.

Query intent moves it the most. Quick factual lookups, local intent and anything a person searches away from a desk skew heavily mobile. Comparison, specification, pricing and procurement research skews desktop, because the searcher has several tabs open and probably a spreadsheet beside them. Anything ending in a long form, a file upload or a purchase above a few hundred dollars pulls desktop even when the research that preceded it happened on a phone.

Industry sets the baseline. Local services, food, entertainment, news and consumer retail run mobile-heavy. Enterprise software, developer documentation, accounting and B2B procurement run desktop-heavy, sometimes inverted from the consumer web entirely. A SaaS product with a marketing blog and an API reference is two different audiences wearing one domain.

Page type splits it inside a single site. This is the practical one:

The skews in that table are directional, drawn from how those intents behave rather than from a published study. Measure your own. A single site-wide percentage is an average of populations that do not resemble each other.

Time of day and day of week move it too. Mobile share climbs through evenings and weekends, desktop peaks in weekday business hours. That has a specific consequence: if delivery runs flat across 24 hours with one fixed device setting, the monthly aggregate can match your site perfectly while every individual hour is wrong. If your product exposes a schedule, run the mobile-weighted portion when your real mobile traffic runs.

You have a measured split. Turning it into configuration takes one piece of arithmetic and one warning.

Blend by campaign volume, not by page count. Say the campaign covers two URLs. URL A takes 60 percent of the visits and measured 75 percent mobile. URL B takes the other 40 percent and measured 40 percent mobile. The blended mobile share is (0.60 x 75) + (0.40 x 40) = 45 + 16 = 61 percent. Not the 57.5 percent you get by averaging the two page percentages, which is the mistake people make whenever the volumes are uneven.

Now the warning, and it is the most common device-split error there is. Mixed is a mode the engine runs, not a proportion you dictate. If it distributes evenly across desktop, mobile and tablet, you have just told your reports that a third of your visitors browse on tablets. Almost no site on the public web has a tablet share above single digits. That one setting produces a more obvious anomaly than any wrong desktop-to-mobile ratio ever would, because tablet is the row nobody looks at until it moves.

When you need proportions the mixed mode cannot express, run separate campaigns and size them yourself:

Campaign C really is optional. If tablet is under roughly 3 percent of your real traffic, running none sits closer to the truth than running a visible slice of it. Underrepresenting a rounding-error device is invisible in a report. Overrepresenting it is not.

Set device in the same pass as your other realism controls. The country list, the referrer configuration and the country targeting describe the same visitor the device profile does, and they are far cheaper to get right together than to reconcile afterwards.

A wrong device split is not subtle. It is arguably the easiest campaign misconfiguration to spot from the outside: device category is a low-cardinality dimension with a stable baseline, so real movement in it shows without statistical work of any kind.

Work the numbers. A site does 10,000 organic sessions a month at 70 percent mobile: 7,000 mobile, 3,000 desktop. Add a 5,000 visit desktop-only campaign. The new totals are 7,000 mobile against 8,000 desktop, so mobile share falls from 70 percent to 47 percent. That is a 23 point move in one month, in one of the most stable dimensions in analytics, with no product launch, no seasonality and no channel change to explain it. Everyone who opens that report sees it, and so does anyone auditing the account.

Here is the tell sheet:

The last two rows are where the device setting collides with your engine choice. The standard Website Traffic engine loads a page and waits: no scroll, no pointer movement, no click. Set that to mobile and you get mobile-labeled sessions that never scroll, a combination real phone traffic essentially never produces. Realistic Traffic scrolls in short steps, moves the pointer along a curved path, engages with the content and clicks through, and on a mobile user agent it taps rather than clicks. When the device label and the behavior have to agree, that difference is what the higher price buys.

The wider pattern-matching approach is covered in how to spot bought traffic in analytics, worth reading from the auditor's side before you configure anything from the buyer's side.

Device is not only a label in a report. It changes what the session encounters, and several of those changes break campaigns quietly.

Viewport changes the layout. A mobile profile renders your responsive template at phone width. Different content sits above the fold, navigation is probably behind a menu button, and elements present on desktop may be hidden entirely. If your flow is scripted to click a link that lives in a desktop-only sidebar, the flow fails and you get a session that arrives and does nothing. Load the target URL in your browser's device emulation at phone width first, and confirm the element the flow depends on is there.

Scroll and interaction change. A mobile viewport shows fewer pixels per screen, so reaching the same depth in a long article takes more scroll steps than in a 1440 pixel desktop window, and step counts tuned on desktop will undershoot. Taps and clicks are also different browser events: anything listening for one and not the other behaves differently, and analytics tracking a button by click handler may not fire at all on a touch profile.

Page weight and load order differ. Mobile profiles meet lazy-loaded images, deferred scripts and consent flows in a different sequence. Sparky Traffic Bot lets you switch off images, CSS, fonts, JavaScript, video and audio per campaign, useful for cost but a change to what your measurement tag sees, since the tag is itself JavaScript.

Conversion paths differ. Multi-step forms, file uploads and payment flows behave differently at phone width. Do not script a desktop-only interaction into a mobile session and then wonder why the completion rate collapsed.

Mirroring is the default, not a law. Four situations make a deliberate skew the correct call.

1. You rebuilt the mobile experience and want it exercised. This is the strongest case. A new mobile template needs hitting across a range of mobile user agents and screen sizes, with your measurement stack running, before the real audience lands on it. Run mobile-heavy on purpose, on a small set of URLs, inside a fixed window.

2. The target pages are genuinely device-skewed and the site is not. Sending a site-average mix at a documentation section that runs 80 percent desktop makes those pages less realistic, not more. Match the pages, not the property.

3. There is no baseline to mirror. A new site, a pre-launch section or a page with a handful of sessions has nothing to copy. Use the closest comparable page you do have data for, then correct once real data exists.

4. You are reproducing a device-specific problem. A layout bug that only appears at certain widths is easier to observe with repeatable sessions at that width than by waiting for organic traffic to stumble into it.

Whichever reason applies, four guardrails keep the skew readable later:

• Name it before you start. One sentence in your own notes: what you are testing, on which URLs, for how long.
• Bound it in time. A defined window, not an open-ended campaign. Skews you forget about become anomalies nobody can explain three months later.
• Keep a control set. Comparable pages you deliberately do not touch, so you can separate a device effect from a site-wide change.
• Annotate your analytics. GA4 supports annotations on reports. A dated note reading "mobile-weighted campaign, docs pages, two weeks" turns a future mystery into a footnote.

What does not qualify: choosing mobile because you heard mobile matters more, or desktop because desktop visitors convert better. Neither device carries algorithmic weight, and if desktop genuinely converts better on your site, the thing to fix is your mobile experience, not your traffic mix.

Run this against your own campaign before it starts.

1. You pulled device category from GA4 for organic sessions only, not all channels.
2. The date range was 28 days, ending at least three days back.
3. You narrowed to the exact landing pages the campaign will target.
4. You cross-checked click share by device in the Search Console Devices tab, same pages, same window.
5. GA4 and Search Console agree within a few points, or you know why they do not and have fixed it.
6. The blend was weighted by campaign volume per URL rather than averaged across pages.
7. Your tablet share reflects reality, and a mixed setting is not silently handing tablet a third of your visits.
8. Device, country and referrer settings describe one consistent visitor.
9. You opened the target URL at phone width and confirmed the flow's target element exists there.
10. If delivery is scheduled, the mobile-weighted portion runs when your real mobile traffic runs.
11. Any deliberate skew has a written reason, an end date and a control set.
12. You noted the campaign start in your analytics so next quarter's report has an explanation attached.

If you are still choosing the underlying product before you get to device settings, Website Traffic is where the desktop, mobile, tablet and mixed control lives.