For as long as most of us have worked in analytics, web traffic came in two flavors. People, who we spend all of our time trying to understand, and bots, who we spend a surprising amount of time trying to get rid of. Every filter, segment and bot rule you've ever built assumes that split.
That split doesn't hold anymore. Somebody opens an app, types "book me a nice room for myself and 2 friends at a mountain resort," and a piece of software goes to a website, reads it, picks a room, fills in the form, and hands the person the browser when it's time to pay. That visitor isn't a person, but it's working for one, with that person's money and that person's instructions. It isn't a bot in any sense your web analytics tools understand either, because it runs a real browser, clicks real buttons, and fires the same analytics events your customers do.
So we wanted to know what that third kind of visitor actually does on a website, what our analytics and testing tools make of it, and whether the things we use to persuade people (the countdown timer, the pre-ticked add-on, the spend-a-little-more-and-get-something-free threshold) do anything at all to a piece of software shopping on someone's behalf.
What this is, and what it isn't
This is hands-on testing of one agent, Meta's Muse, over six days, from October 27 to November 1, 2026. Most of it happened on sites we built for the purpose, with two quick checks on live brand sites.
It is not an academic study, it doesn't cover every agent, and it isn't exhaustive. Some findings rest on a handful of runs, and a few rest on one. We say which as we go. Meta can change how Muse works any time it likes, so treat every finding here as a snapshot of how one agent behaved in one week.
The point of sharing it is the method as much as the findings. Everything we did, you can do on the brands you work with, and we'd love it if you did, because the more of us who look at this, the sooner we'll know what's real and what isn't.
How we tested
We built two sandbox sites: a hotel booking site and a home and garden shop. We set them up the way a brand would, with Google Analytics 4, Adobe's analytics stack and Adobe Target on every page, and on the later builds a CDN in front, so we'd see exactly what those tools see.
Then we added three layers of our own, because we didn't want to rely on the tools we were testing:
A server log of every request, with its full headers
The CDN's view of each connection
A small script in the page that recorded what the visitor's browser looked like, how it moved, clicked and typed, which offer it was shown and what it did with it, and every analytics request the page sent
Each run was a fresh conversation with Muse, starting from its own unique link, and the link decided which version of the site the agent got: the control, or one of the treatment variants, served up by Adobe Target on our first build and by the site itself on the later ones, such as a discount code, a flash sale with a countdown, a pre-ticked add-on, a room upgrade, a bundle or free valet parking once you spend $50 on extras. That way we always knew what it saw.
The prompts ranged from tightly specified ("pick the best room within that budget") to the way people actually type, including one my daughter wrote for a family trip and two written from a short brief about what to ask for. When Muse asked to complete a purchase we approved it as asked, paid with test cards, or took over the browser at payment. We saved every word it said back.
All in, that was 45 sessions: 43 on our own sites and 2 on live brand sites, a large retailer and a large publisher. For the live sites, where we couldn't see the server logs, we added a made-up parameter to the link (something like `?lab=run01`) that the site ignores but its analytics records in the full URL, so we could find the agent's visit in the brand's own reporting afterward. (Check that your setup keeps the query string; most do.) If you want to try this on your own site, that one trick does most of the work.
How an agent browses to complete a task
It reads your page twice, with two different readers
When Muse gets a link, the first thing to arrive is a quick read of the page's raw code from a Meta fetcher. It doesn't run scripts and it doesn't load styles, it just takes the HTML and identifies itself as Meta. Only when Muse needs to look closer, or do something, does it open a real Chrome browser that runs the page like a person would.
Sometimes the browser never comes. In one run on our shop, Muse decided everything from that first read and its memory of an earlier chat, and our analytics never saw it at all. On the publisher's site it told us exactly what it was doing: "I'm checking the live page for what it suggests after the article ends, since the text version didn't show that section." The text version was the fetcher's copy. The section it was missing was added by the page's testing tool, so only the browser could see it.
It reads text, not pixels
Even in the browser, Muse isn't looking at your page the way a person does. It picked up a line of text we'd hidden visually but left available to screen readers, and it skipped text hidden with `display:none`. That's the same rule a screen reader follows, so what the agent "sees" is closer to your page's text layer than to the page you designed.
It researches before it acts
Given a vague request, Muse asked questions first. Asked to find a pot for a plant that had outgrown its old one, it wanted the size, the placement and the material before it looked at a single product. Given my daughter's request for a family of six, it said "I won't book anything, just pull the options to compare" and read five pages before it booked a thing.
It shops around, and tells the customer
On our shop, Muse left the site mid-task to price the same pot elsewhere, then reported back that the cheaper option was "$19.97 and the same size and material, but from [a big-box store], not your shop." It still recommended ours, and bought it when told to. BUT, the customer knew exactly what they were giving up, because the agent told them.
It remembers
Our shop's order confirmation said the order wouldn't be fulfilled (it's a sandbox, after all). In the next conversation Muse didn't open the shop at all. It went straight to other retailers and said "I am not ordering from there again." Our demo notice caused that, so it's a single, slightly artificial run, but the real version isn't hard to imagine: a store that let a customer down once may not get a second visit from that customer's agent.
It takes your copy literally
Asked for a room with "secure parking" for a friend's nice car, Muse checked our parking copy and reported back: "There is no separate secure or locked parking option listed, and the words secure and locked do not appear." We had covered valet parking in a garage. We just never called it secure, so as far as the agent was concerned, we didn't offer it.
It works around missing information
On the retailer's site, a test variant removed the delivery-date block from the product page. Muse said the site "wouldn't load a dated delivery estimate," so it went and found the shipping policy page, and worked out the dates itself. The test took the information away from the page, and the agent got it anyway from a page the test never touched.
It lets the customer's instruction decides almost everything
This was the strongest pattern in the whole project. Same agent, same site, same rooms:
"pick the best room within that budget" chose a room right at the stated budget, 16 times out of 16
"find me the best deal" chose the cheapest room
"it's our anniversary… make it a nice weekend" chose a better room every time
The agent had its goal before it ever reached our site, and the site mostly helped it find the thing it was already looking for.
When the instruction left the choice open, the page made it. For example, when Muse was told simply to "book a room for two." Muse took the first room on the list that fit two guests. With the cheapest room listed first, that was the cheapest room, 7 times out of 7. When we flipped the list so the most expensive rooms came first, it took the first room sized for two from the top instead, a $438 stay rather than $298 (one run). Same agent, same prompt, $140 more, and the only thing we changed was the sort order.
It can't get in to every site
Muse was able to figure out how to get through a press-and-hold bot check on the retailer's site we tested, the kind built to stop automated browsers, by doing what a person does: pressing and holding. However other websites draw a harder line. For example, Amazon, for one, has blocked Muse's agents (MIT Technology Review).
What this means for you
If you're the optimization strategist: Every test you run now includes some visitors whose goal was set somewhere you can't see. A treatment that helps a deal-seeker can be irrelevant to someone told to find the best room under $500. When you read a result, ask which kinds of instructions your treatment could actually change, and make the facts an agent checks (size, fit, delivery, terms) plain on the page in words. And when the customer's instruction is loose, your default sort order could just be making the choice for them.
If you're the data implementer: Your tags only ever see the second reader. The fetcher's read of your page never runs your tag manager, your analytics or your testing tool, so it leaves nothing in your data, and any change your testing tool makes in the browser doesn't exist for it. If you want a record of agents reading your pages, it lives in your server or CDN logs, so make sure those are kept and can be joined to the rest of your data.
If you're the data analyst: An agent's research can leave no trace in your analytics at all. When it does show up, it can be a single direct visit that reads one page and leaves, after the decision was already made somewhere you never saw.
Showing agents what people can't see
Anyone who did SEO in the early days remembers hidden text and cloaking: White keywords on a white background, or a different page served to the crawler than to the people. It worked, until Google made it a penalty (both are still on its list of spam policies). With agents reading pages for people, we wanted to know whether the same tricks work again, and whether they could happen to you by accident.
So we hid four facts on our hotel's home page, none of them mentioned anywhere a person could see, each hidden a different way:
Dogs welcome for $25 a night, in the HTML but hidden with CSS, the way our own booking page hid the offers a visitor didn't get
Mountain bikes for $32 a day, sent only when the visitor identified itself as Meta's fetcher
Free kayaks, added by a script and hidden from view
A gym that opens at 5:30, added by a script, hidden from view but left available to screen readers
Then we asked Muse whether we could bring a dog, rent a bike or a kayak, and use a gym.
Its first answer came entirely from one fetch of the page's HTML. It told us dogs were welcome for $25 a night and bikes rented for $32 a day, both as what the page says, with nothing to say a person would never see either one. Kayaks and the gym didn't exist for it, because they lived in a script the fetcher never runs.
When we asked it to open the page in its browser and look again, it found the gym line (screen-reader text) and skipped the dogs and kayaks (hidden from view). Then it went back to the raw HTML, saw that its two copies of the page disagreed, and picked a side: "So on the verified page text: no kayak, no gym, dog yes, bike yes." It decided its own browser was the unreliable one, because it had "missed the dog and bike lines that are plainly on the page." Neither line was on the page any person could directly see. And one of them was only ever sent to Meta.
That was one run on a site we built, so don't take it as a law. But it's a clean result, and it means two things. The version of your page an agent trusts can be one you never showed a customer, and anyone willing to serve the fetcher its own version of the page can put words in the agent's mouth. Google wrote rules for this. For agents, as MIT Technology Review put it: "These rules are still being written."
It doesn't take a bad actor, either. On the large retailer's site, a live test variant replaced the real delivery dates at checkout with a simpler "Arrives in 3-6 business days" message. The code did it a common way by shrinking the original text to zero size and laid the new copy over the top. A person looking at that checkout saw delivery windows. Muse, in the same browser at the same moment, quoted us the windows AND the hidden delivery dates underneath, which showed the cheaper and the faster shipping options arriving on the same day. A customer in that variant couldn't know that. The customer's agent could.
What this means for you
If you're the optimization strategist: Hidden isn't hidden to an agent. If a variant shouldn't exist for someone, take it out of the page, don't just hide it. And whatever you think about cloaking, assume your competitors are thinking about it too.
If you're the data implementer, and you're the one coding test variants: How you hide something decides who reads it. Removing it, or display:none, kept it from the browser reader in our tests. Zero-size text, overlaid copy and screen-reader-only text did not. Anything sitting in the HTML, including the variant a visitor didn't get, is fair game for the fetcher, which never runs your testing tool's scripts at all, so to that reader every client-side test looks like the control.
If you're the data analyst: The variant your testing tool says an agent was in doesn't tell you what the agent read. It may have read the hidden version, the control's HTML, or both.
How persuasion and offers land
Most of the optimization playbook was built for a person in the moment of deciding: A bit of urgency, a sensible default, a better deal for spending a little more. Here's what those did to an agent working from someone else's instructions.
| What we tried | What Muse did |
|---|---|
| A pre-ticked add-on | Removed it 5 times out of 5, and told the customer 4 times: "An optional breakfast for two… was pre-checked during checkout and I removed it, since you did not ask for it." |
| A countdown timer | Never mentioned it in 5 runs, with no visible effect on what it did |
| A flash sale | Took it 3 times out of 3 when it put a better room inside the budget it was told to use. Ignored it when told to find the best deal |
| A discount code | Used it once in 7 runs |
| A cheaper non-refundable rate | Kept the flexible rate |
| A room upgrade | Turned it down both times. In another run it chose that same suite on its own, but offered as an upgrade for $80 more a night, it clicked "No thanks" |
| A bundle | Took none of the 4 it was offered |
| Free valet once you spend $50 on extras | Took neither offer |
| An extra night at 30% off | Turned it down both times: "that would have changed your dates" |
| The order rooms were listed in | Decided the room whenever the instruction didn't (more on that above) |
Add it up and Muse took none of the 10 offers that would have raised the bill. It wasn't against spending. It chose better rooms on its own whenever the customer gave it a reason, and when my daughter's prompt asked for daily breakfast for a family of six, it added breakfast for all six, because that was on the list. When we told it "no budget… build the perfect weekend package," it planned every extra we sold, $264 on top of a $598 room. It treated extra spend as the customer's decision, and it spent when the customer had made it.
The pre-ticked add-on is the one we'd watch. In SusBench, a published study of how computer-use agents handle manipulative page design, 29 people undid a preselected add-on only 44% of the time, and the five agents tested managed between 13% and 37% (Guo et al., 2026, Table 5). Muse removed ours every time. Those were different agents on different tasks, and five runs is five runs, but it's a reason to test your own defaults rather than assume.
We didn't test scarcity messages or social proof. SusBench did include fake social proof, and the agents ignored it about 93% of the time.
What this means for you
If you're the optimization strategist: An offer that adds spend has to already be on the customer's list, because the agent won't add it for them. Urgency didn't register in our runs, and a pre-ticked box costs you twice as the agent removes it, then tells the customer it did. And put offer prices and terms where an agent can find them while it's still comparing. On the family booking, Muse couldn't confirm breakfast, because the price only appeared inside the booking flow.
If you're the data implementer: Standard ecommerce tracking won't show you what an agent did with an offer. A pre-ticked add-on removed before checkout, a code that was shown and never used, an upgrade clicked away. They all look like nothing happened. If you want to read offers on agent traffic, track each offer being shown, and what happened to it (accepted, declined or removed), as events of their own.
If you're the data analyst: On agent traffic, an offer's take rate mostly measures what customers told their agents. Expect upsells and bundles to read flat or worse in any segment with a lot of agents in it.
What your measurement sees
Here's how one week of Muse looked to off-the-shelf analytics (GA4, Adobe) and testing tools (Adobe Target, Optimizely).
It looks like a person. Its browser carried none of the usual automation flags, Adobe's bot detection scored it zero, and it fired the same page views, form starts, add to carts and purchases a person does. Because its cloud browser keeps cookies between conversations, every run on a site came from the same returning visitor (one GA4 client ID across 24 runs on one of our sites), located in the same region of the person it was working for. It arrived with no referrer, so analytics filed it as Direct, and it counted as engaged from its second page on.
The things that do separate it from a person, your tools don't collect. Software graphics with no GPU, a window that never has focus, every character typed one at a time at a steady 72 to 90 milliseconds apart with no paste or autocomplete, and a fraction of a person's mouse movement, with clicks landing near the center of buttons. We only know those because we built a script to record them.
It gets counted in your tests. The testing tools bucketed it like anyone else, and because of those cookies it stayed in the same bucket across conversations. On the publisher's site, their analytics recorded our agent's visit in a live recommendations test as one new Direct visitor who started and engaged with an article, 26 seconds on site, one impression in the test. A second visit we made, in the same experience of that test, was shown different products, so the experience label didn't say what the agent actually read.
Your results can go flat while behavior changes underneath. In our first round, every version of the hotel produced the same booking total, so the test read as no difference. Underneath, the flash sale changed which room the agent booked every single time.
Most of what it does never reaches your tags. The fetcher's reads never run your analytics code. On the publisher's site, the agent told us it read a text version of the page before opening its browser, and analytics saw one visit. And some of what does arrive is misleading. When Muse got a purchase ready and a person took over the browser to pay, analytics saw one ordinary customer who converted. In one run, Muse stopped at the review step over a payment rule our site doesn't have, and analytics recorded an abandoned checkout.
How big is it today? On the large publisher's site, visits matching Muse's analytics signature (Linux, a current version of Chrome, Direct and a common screen size) came to about 0.009% of all visits, even in the week they peaked.
One more reason it's easy to miss. The usual cleanup for junk traffic is to keep only engaged sessions. Kevin Indig found a site where "GA4 recorded 409,000 Direct sessions, of which only 198 counted as engaged" (Growth Memo). That filter does a nice job on bots. Muse's sessions were engaged, so it keeps them.
What this means for you
If you're the optimization strategist: Some share of every test population is agents carrying out instructions you can't see, and they can flatten or shift a result for reasons none of your reports will show.
If you're the data implementer: Nothing in a default setup flags an agent. If you want to know, you'll have to collect it yourself (next section).
If you're the data analyst: Direct, engaged visitors aren't all people, and an agent that has been to your site before comes back as a returning visitor, not a new one. A conversion can be an agent's work finished by a person, and an abandonment can be an agent stopping over something that isn't there.
So how do you classify something your tools can't see?
The honest answer is that you collect what your tools don't, and you accept that some of it can't be collected at all.
If you're the data implementer, add the signals yourself. A small script can record the things that separated Muse cleanly in our tests such as graphics rendered in software, a window that never has focus, typing cadence (and whether anything was pasted or autofilled), how much the pointer moves and where clicks land, and a browser that identifies only as Chromium. Turn those into a label or a score in the page, and send the label to your analytics as a custom dimension. Send the label, not the raw fingerprint, and get your privacy team involved before you ship it. At the server or CDN, label the requests where the agent's fetcher identifies itself, because that's the only place its reads show up. Expect to maintain all of this, since an agent can change any of these signals in an update.
If you're the data analyst, use the proxy you already have, as a monitor and not a classifier. In both GA4 and Adobe you can build a segment for Linux, a current version of Chrome and Direct traffic. Don't limit it to new visitors as an agent's browser keeps its cookies, so after its first visit it comes back as a returning visitor. On the publisher's site, the broad version of that segment was mostly data-center traffic, likely other automation, so it won't find agents for you. It will tell you whether something shaped like them is growing inside your test populations. Read your results with it and without it, and classify by page or event, not just by visitor, because an agent and a person can share a visit.
If you're the optimization strategist, design for a segment you can't see. Put the changes you want agents to see in the HTML. Take hidden variant copy out of the page. Put prices, terms and delivery details where an agent reads them, and write your test plans knowing that some of your visitors arrive with their minds already made up. And know what you can't classify. Agents that run as an extension inside the customer's own browser use that person's machine, network and cookies, so to your analytics they are that person. We didn't test one, but there's nothing for your tags to see. And the fetcher's reads never reach your analytics at all.
What we didn't cover, and how to run it yourself
This is one agent, on one account, over six days. That account remembered our sites, our sites carried demo notices the agent could read, many findings rest on a single run, and we only ran one person through the same task for comparison. Meta can change Muse tomorrow. Treat all of it as a starting point.
If you want to run it on a brand you work with:
Pick a page with a live test, or build a small sandbox.
Add a parameter to the link that your site ignores and your analytics keeps, so you can find the visit afterward.
Give the agent a prompt a real customer would write, one conversation per run.
Save every word it says back.
Find the visit in your analytics and your testing tool, and compare what they recorded with what the agent told you.
Look at your page the way the fetcher does, with the raw HTML and no scripts, and see what it says that your customers can't see.
Then tell us what you found. We've shown you what one agent did on a handful of sites in one week. What it's doing on yours, right now, is the more interesting question.
About the Author
jason thompson is the CEO of 33 Sticks, an analytics boutique that helps companies understand what their data is actually telling them, not what the industry average says it should. If you want to run this research on your own sites, or find out how many agents are already in your tests, let's talk.
