Most conversations about live chat assume the widget is there for everybody. Often it should not be. A team that only sells in three countries, a service that only supports desktop workflows, a business whose overnight traffic is almost entirely bots and scrapers: each has a good reason to decide, before the launcher ever paints, that a particular visitor does not get a chat entry point at all.
MyLiveChat has a screen for exactly this. It is called Access Filter, it sits with the other traffic controls near your administration settings, and it evaluates three signals about the visitor: the country their IP resolves to, the language their browser asks for, and whether the request came from a mobile device. It is a small screen, and it is easy to configure it to mean the opposite of what you intended. This guide is mostly about that.
What the filter actually decides
The filter runs when the chat runtime loads, before anything is drawn. It produces one of three outcomes: leave the visitor alone, hide chat entirely, or show the offline message window instead of a live conversation.
Those last two are meaningfully different. Hiding chat means the runtime stops and returns nothing. There is no launcher, no chat link, no widget, and nothing in the page for the visitor to discover. It is not a CSS trick that a curious person can undo in developer tools; the response simply ends.
Showing the offline window is the softer option. The visitor still gets an entry point, but the system treats your team as unavailable, so they land on your offline message form rather than a live queue. If your goal is to stop taking real-time conversations from a segment while still collecting their questions, this is the setting you want. If your goal is that a segment should never see chat at all, the first one is.
Choose between them by asking what you want to happen to the message the visitor was going to send. Hiding chat throws the intent away. The offline form keeps it as a lead you can answer later.
Allow mode and block mode
The mode setting decides how a match is read, and it inverts the whole rule.
In block mode, the visitors who match your signals get the action. You are naming the traffic you want to turn away. This is the mode people expect, and the one most rules should use.
In allow mode, the visitors who do not match get the action. You are naming the only traffic allowed to reach you, and everybody else is turned away. This is far more aggressive than it looks on the screen, because it makes the filter a default deny: every visitor you did not think to include is excluded, including the ones you have not encountered yet.
The practical consequence is that allow mode punishes incomplete lists, and the failure is silent. Nobody emails to tell you the chat widget was missing. If you run allow mode, revisit the list whenever you enter a new market, and treat any report of a missing widget as a filter question first.
The three signals are combined with or
This is the single most misread part of the screen, and it is worth stating plainly: the country rule, the language rule and the mobile rule are combined with OR, not AND.
The evaluation checks the device rule first. If that matches, it stops and the visitor is a match. Otherwise it checks the browser language, and if that matches it stops. Otherwise it checks the country. A visitor is a match if any single one of your configured signals matches.
So adding a second signal always widens the net. If you set a country list and then add a language list hoping to narrow the rule to people who are in that country and speaking that language, you have done the opposite: you now catch everyone in those countries plus everyone using those languages anywhere in the world. In block mode that means you are turning away more people than you meant to. In allow mode it means you are letting more people through.
There is no AND anywhere in this screen. If your policy genuinely needs a conjunction, this is not the tool for it, and you should express the rule with the signal that matters most and accept that the others are unavailable.
What each signal really measures
Each of the three signals is measuring something narrower than its label suggests, and the gap is where surprises come from.
Country comes from IP geolocation. The visitor's address is looked up and compared against your list. That means a VPN, a corporate proxy that egresses in another country, or a mobile carrier routing through a different region will all report the wrong country. It also means that when geolocation returns nothing at all, the country signal simply does not match. In block mode that is harmless. In allow mode it is not: a visitor whose IP cannot be resolved fails your allow list and loses chat, having done nothing unusual.
Language is the browser's first preference only. The check reads the top entry from the visitor's Accept-Language list, not the whole list, so somebody whose browser prefers one language but also accepts yours is judged on the first one. Matching is done two ways: a two-letter entry matches any regional variant, so a rule for the generic code catches every regional form of it, while a full regional code only matches that exact form. Prefer the two-letter form unless you specifically mean one region, and remember that browser language is a setting on a device, not a statement about a person.
Mobile is a user-agent pattern. The rule matches a fixed list of well-known mobile identifiers. It is a reasonable proxy for phones and tablets and it is not a device database, so treat it as a broad brush rather than a precise segment. If mobile visitors are a real part of your traffic, read how chat behaves on small screens before you decide to exclude them, because the usual reason people reach for this rule is a layout problem that has a better fix.
How it fails, and which way
Two behaviours are worth knowing because they determine what happens on a bad day.
First, the filter fails open. If the evaluation throws an error for any reason, the result is no action, which means the visitor sees chat normally. A geolocation lookup that breaks will not silently hide your widget from everybody. For a revenue-carrying channel that is the right default, but it does mean the filter is not a security control and should never be the thing standing between a visitor and something sensitive.
Second, on the current widget runtime the offline action also stands the AI assistant down for that visitor. If you have AI chat answering out of hours, a visitor caught by an offline rule will not get the assistant either; they get the offline form. That is deliberate rather than accidental, and it is usually what you want, because an admin who routed a segment to a lead capture form rarely meant for a bot to intercept it first. It is still worth knowing before you assume AI coverage is universal. Behaviour here differs between widget generations, so confirm on a real page and check which widget version you are running if the result surprises you.
Testing a rule before you trust it
A filter is one of the few settings where you genuinely cannot tell from the screen whether it worked, because the correct result is usually an absence. Test it deliberately.
- Load your own site normally and confirm the widget still appears for you. Do this first, every time, before checking anything else.
- Change your browser's preferred language to one on your list and reload. This is the cheapest way to exercise a language rule without leaving your desk.
- Load the site on a phone on mobile data, not office wifi, if a device or country rule is involved.
- Check a page you did not think about. Filters apply to the whole widget, so the pricing page and the support page are both affected.
- Write the intended rule as one sentence and give it to somebody else to test blind. If they cannot predict the outcome from your sentence, the rule is too complicated to keep true.
When a filter is the wrong answer
Reaching for this screen is often a sign the real problem lives elsewhere, and it is worth checking before you hide a channel from anybody.
If the motivation is abuse or nuisance traffic, a country rule is a blunt instrument that costs you legitimate visitors in those countries. Specific address rules and the practices in handling spam and time wasters target the behaviour rather than the geography.
If the motivation is that nobody is staffed for a language, the honest fix is your operating hours and your offline message, not invisibility. A visitor who finds an offline form and a clear answer about when you reply is better served than one who finds nothing and concludes your business does not exist.
And if the motivation is cost, remember what a hidden widget actually removes: it removes the question, not the customer. The person still had a problem, and they now solve it by leaving. Read live chat versus contact forms for the cases where a form genuinely serves that visitor better, because some of them do.
What to measure
The number that matters is the one the filter suppresses, and by design you cannot see it in your chat reports, because those conversations never started.
So measure around it. Watch total conversations per day before and after a rule goes live, and expect a step change proportional to the traffic you excluded; if it drops much further, the rule is wider than you think and the OR behaviour above is the first place to look. Watch offline messages if you used the offline action, since that volume is the intent your rule preserved. And keep a dated note of why each rule exists, because a filter is a setting that outlives the person who set it, and next year somebody will ask why chat does not appear in a market you now sell to.