Regex for GA4 & Search Console. Better filters. Better questions.

First, get the match right. The same pattern tells two different stories.

Regex describes text patterns. It filters values in a field you select; it does not understand a customer journey. Start with the platform, the field, the operator and the case handling. Google documents full, case-sensitive matching as the Analytics default. Search Console documents partial, case-insensitive matching by default.

Both tools use the RE2 syntax, which supports alternation, character classes, anchors and repetition but not lookahead, lookbehind or backreferences. For a simple exclusion, use the interface’s Doesn’t match operator. For complex include-and-exclude logic, use a segment, an export or the API. A leading (?i) makes a match case insensitive; Search Console documents (?-i) to require case-sensitive matches. Record whichever you choose.

Event creation deserves its own review. Google says those rules run in the browser and can suffer from expensive backtracking, so a pattern that is fine for a report is not automatically safe there.

The 13 characters you will actually use

Every recipe in this guide is built from these. Each example below was run in Google’s RE2 engine.

Boundary and token examples target English text. Review Tamil and other languages with your actual strings and a suitable Unicode-aware pattern. Paste the pattern without JavaScript-style enclosing slashes. When you need a word boundary, \b is ASCII in RE2, so \bcost\b avoids costume in English text.

Choose the field before you copy the pattern.

A Search Console Page value is a full URL. A GA4 page-path dimension is a path. Landing page + query string includes its query string, and Session source holds a source value, not a whole URL. Test the exact field. In GA4, add a Web platform condition when you analyse mixed web and app data.

A GA4 exploration filter restricts that exploration. Segments can define users, sessions or events. If you want later purchases from sessions that viewed a collection, define the session population. Filtering only page events can remove the purchase events you meant to inspect.

Use simple exact or contains conditions when they answer the question. GA4 comparisons document their own operators, so do not assume every report has the same regex menu. The recipes use Explore for a consistent starting point.

Climb the Filter Ladder only as far as the question needs.

I treat filtering as four rungs. Start on the lowest one that can answer the question, and climb only when it cannot. Most wasted analysis time comes from starting at rung three.

Run both and compare the rows. If the AI configuration and the regex disagree, the disagreement is the finding: one of them is grouping values you did not intend.

See the matches before you trust the filter.

Pick a recipe, or choose Custom pattern to test your own. Paste sanitised values from the same field, one per line. Everything runs in your browser; nothing is sent anywhere.

Start with the decision your business needs.

Each recipe defines one string group and names the question, the field, the match settings, the review point and the next decision. The patterns are original and built on the documented matching rules. Intent labels are working hypotheses for manual review. Paths, product codes, names and custom events must match your implementation.

No recipes match this combination. Clear the search or select another business type.

Separate AI traffic, AI answers and AI-assisted analysis.

First check Session default channel group. Google documents an AI Assistant channel, and places visits from Google AI Overviews and AI Mode within Organic Search. An assistant-domain regex is therefore a supplementary investigation, not a universal AI visibility measure.

If your business needs a custom channel definition, copy a group, use your observed source values and inspect the rule order: traffic belongs to the first matching channel. Custom groups can be applied retrospectively in reports, while audience behaviour and primary-channel changes have different timing. Keep a dated definition.

I prefer an explicit source allowlist over an expression such as .*ai.*, because a broad substring catches unrelated sources. Recipe 32 anchors known domain values and deliberately rejects chatgpt.com.evil.test. The list still needs maintenance as sources change.

For Google AI visibility, use the dedicated generative AI performance report rather than a query regex. A query pattern does not create an AI-feature attribution label for GA4 sessions.

A practical investigation, from question to next action.

Example question: “Do our software comparison pages answer the questions visible in Search, and do sessions landing there take a useful next step?” This is an illustrative analysis plan, not a claim about a real property.

1. Define the query cohort. Apply the SaaS comparison pattern (recipe 27) in Search Console and review the actual queries.
2. Inspect the landing pages. Use the Pages tab with a consistent date range. Save the query group and the pages shown.
3. Define the GA4 population. Use those landing paths in a session-focused exploration, keeping acquisition context and compatible metrics.
4. Validate useful actions. Check that trial or lead events are implemented and mean what the business needs.
5. Choose the investigation. If comparison content omits a recurring criterion, improve it. If the form fails, fix the journey. Collect evidence before deciding.

Treat this as a comparison of aggregated evidence. A query table and a session table give no person-level link between a Google query and a GA4 conversion. Search Console and Analytics differ in collection, aggregation and time-zone handling, so their totals are not expected to reconcile perfectly.

Debug the definition before you rewrite the strategy.

Filtering a report changes the view. GA4 incoming data filters change collection and can permanently exclude future data, so do not activate a collection exclusion just to explore a question. If the real problem is accidental email or query-parameter collection, look at prevention and GA4 data redaction. A display filter is not a privacy fix.

Search Console may omit anonymised queries, so matched and non-matched totals can differ from the unfiltered total. The built-in branded and non-branded filter is useful where available, and Google documents eligibility limits including low-impression sites. A manual regex stays useful when you need a transparent definition or the built-in option is unavailable.

Save the definition, then automate the repeatable work.

Once a segment is useful, save its definition with a few positive and negative tests. Keep examples that should fail, including similar path names, hostile-looking domain suffixes and wrong event names. That makes later edits easy to review.

In a GA4 Data API workflow, choose the match type explicitly. The API offers FULL_REGEXP, PARTIAL_REGEXP and caseSensitive, plus logical filter groups. Set them deliberately rather than expecting the interface defaults to carry over.

{
  "dimensionFilter": {
    "filter": {
      "fieldName": "sessionSource",
      "stringFilter": {
        "matchType": "FULL_REGEXP",
        "value": "^(chatgpt\\.com|perplexity\\.ai|claude\\.ai)$",
        "caseSensitive": false
      }
    }
  }
}

{
  "startDate": "2026-09-01",
  "endDate": "2026-09-30",
  "type": "web",
  "dimensions": ["query", "page"],
  "dimensionFilterGroups": [{
    "groupType": "and",
    "filters": [
      { "dimension": "query", "operator": "includingRegex", "expression": "(?i)\\b(pricing|demo)\\b" },
      { "dimension": "query", "operator": "excludingRegex", "expression": "(?i)\\b(acme|examplebrand)\\b" }
    ]
  }],
  "rowLimit": 25000
}

An assistant can help draft a pattern or group exported rows. Ask it to name the field, engine, match mode and expected counterexamples, then test its output against real sanitised values. That is the boundary I want in agentic SEO work: tools organise evidence, and human review decides what the evidence supports.

Use the SEO checklist when your next action concerns access or content quality. If you need crawler behaviour rather than visit behaviour, continue with the log file analysis guide. They are related investigations with different inputs.