Skip to main content

Filtering & Search

TagDragon offers multi-level filtering to help you isolate specific tracking requests from potentially hundreds of entries. Combine text search, event type, HTTP method, status code, and user ID filters to find exactly what you need.

The search input in the toolbar lets you filter requests by text content.

  • What it searches: URL text, parameter names, and parameter values
  • Keyboard shortcut: Ctrl+F focuses the search input
  • Debounce: 150ms delay after typing stops — prevents excessive re-filtering while typing
  • Real-time results — The request list updates as you type
  • Clear — Click the × button or press Escape to clear the search

Use cases

  • Search for page_view to find all page view events
  • Search for a specific URL fragment to isolate requests to a particular endpoint
  • Search for a parameter value to find requests containing a specific user ID or transaction ID

Event Type Filter

Filter requests by event name or hit type using the event type popover.

  • Available options — Dynamically populated based on captured events in the current session
  • Multi-select — Choose one or more event types to include
  • Clear — Deselect all to show all events again

Use this to isolate specific event types like page_view, purchase, add_to_cart, or custom events.

HTTP Method Filter

Toggle between showing all requests, only GET, or only POST.

  • GET — Most tracking pixels use GET requests with parameters in the URL query string
  • POST — Server-side event APIs (Facebook CAPI, GA4 Measurement Protocol) use POST
  • All — Show both (default)

Useful for isolating server-side events (POST) from client-side pixels (GET).

Status Code Filter

Filter requests by their HTTP response status code.

  • 200 — Successful responses
  • 204 — Successful with no content (common for tracking pixels)
  • 301/302 — Redirects
  • 404 — Not found — the endpoint doesn’t exist or the URL is wrong
  • 500 — Server error — the tracking server had an issue

This filter is especially useful for finding broken tracking implementations. Filter for non-200 statuses to quickly identify failing requests.

User ID Filter

Find requests containing specific user identifiers.

  • What it matches: Common user ID parameters like client_id, user_id, uid, _cid, and similar
  • Enter a value — Type the user ID or client ID you’re looking for
  • Partial match — Supports partial matching for convenience

Use this to trace all requests associated with a specific user across multiple providers — useful for data audit and privacy compliance checks.

Filter Chips

Active filters are displayed as chips in the Filter Bar below the toolbar.

  • Visual overview — See all active filters at a glance
  • One-click removal — Click the × on any chip to remove that specific filter
  • Filter type label — Each chip shows the filter type and value (e.g., “Status: 404”, “Method: POST”)

Combining Filters

All filters work together with AND logic — a request must match ALL active filters to be shown.

Example workflows

Find failed GA4 events:

  1. Type google-analytics.com in the search
  2. Set status code filter to exclude 200 and 204
  3. Result: Only failed GA4 requests are visible

Isolate purchase events from Facebook:

  1. Type facebook in the search
  2. Select purchase in the event type filter
  3. Result: Only Facebook purchase events are visible

Find POST requests with errors:

  1. Set HTTP method to POST
  2. Set status code to 500
  3. Result: Only server-side events with server errors

Clearing Filters

  • Individual filters — Click × on the filter chip
  • All filters — Use the “Reset Filters” button in Settings
  • Note: Resetting filters does NOT affect hidden providers (those are managed separately in the Provider Filter)

Tips & Best Practices

  • Combine text + event type — The most powerful combination for isolating specific tracking events
  • Status code for error debugging — Filter for 4xx and 5xx to quickly find broken tracking implementations
  • User ID for privacy audits — Find all requests associated with a specific user to audit what data is being collected
  • Clear between tests — Remove filters before testing a new interaction to ensure you don’t miss anything
  • Filter chips as documentation — The visible filter chips show you exactly what’s being filtered, preventing confusion

Was this page helpful?

Start typing to search docs...