Summary
Yatra can send optional, opt-in usage telemetry to help improve the product. It is off by default until you enable it (e.g. in Yatra settings or during setup).
Telemetry is technical and configuration-oriented: environment details, coarse usage counts, feature flags, and no booking content, traveler personal data, payment card data, API keys, or email addresses.
What we do not collect
- No customer or traveler personally identifiable information (names, emails, phone numbers, addresses).
- No booking records or trip content (itineraries, notes, messages).
- No payment details (card numbers, gateway secrets, transaction payloads).
- No API keys, license keys, or passwords.
- No full posts, pages, or private site content (only coarse signals such as whether Yatra blocks appear in published content, as described below).
- No hashed emails or user account identifiers for telemetry.
When and how it is sent
- Transport: HTTPS
POSTwith a JSON body. - Headers (identify the sender plugin):
X-Plugin: yatra,X-Product: yatra,X-Version: <Yatra version>. - Schedule: roughly weekly via WordPress cron, plus an immediate send when you first opt in, and a fallback attempt if a sync has not succeeded for an extended period while an administrator is in the dashboard.
- Efficiency: identical payloads may be skipped within a 24-hour window to avoid duplicate sends.
- Destination: default remote endpoint is configurable; sites may point to a MantraBrain collect URL (or another receiver you configure). A central hub may ignore requests that match block rules (e.g. local/test sites), if configured there—not in Yatra itself.
Identification & site context (anonymous instance)
| Data | Purpose |
|---|---|
Random instance ID (instance_id, UUID) | Distinguish one install from another without identifying a person. |
| Site URL | Identify which site the snapshot belongs to (same as your public site_url()). |
| Blog ID (multisite) | Distinguish subsites on a network. |
Timestamp (sent_at) | When the payload was built. |
Environment & WordPress (system)
| Data | Notes |
|---|---|
| WordPress version | Compatibility. |
| PHP version | Compatibility. |
| MySQL version | Compatibility. |
| Web server software (if available) | e.g. Apache/Nginx string when exposed. |
| SSL enabled | Boolean. |
| Timezone & locale | Site configuration. |
| Multisite | Boolean. |
| WP-Cron disabled | Boolean (DISABLE_WP_CRON). |
| External object cache | Boolean. |
| Active theme name & version | Not your page content. |
| Count of active plugins | Aggregate number only in this block. |
Yatra (free) — configuration & coarse usage
| Area | Examples of what may be sent |
|---|---|
| Versions & flow | Yatra version, booking flow mode (e.g. pageless). |
| Onboarding | Whether onboarding started/completed, last step, drop-off step, abandoned-setup heuristic. |
| Counts | Number of trips, destinations, bookings (counts only—not titles or customer data). |
| Features | Enquiry forms enabled; which payment gateway keys are enabled (identifiers only, not secrets); email templates customized (boolean); Yatra blocks/widgets used (booleans); Elementor/REST/beta flags (via filters where applicable). |
| Milestones | Whether the first trip / first booking was ever created (flags). |
| In-product engagement counters | e.g. upgrade CTA clicks / upgrade page views (aggregated counters). |
Yatra Pro (if applicable)
If Pro is present, the payload may include non-secret Pro signals, for example:
- Whether Pro is installed/active and Pro version.
- License state/tier (as exposed by Pro via filters—no license key).
- Days since activation (telemetry-local timestamp).
- Enabled Pro module slugs (list of module identifiers).
- Feature toggles (coupons, recurring tours, seasonal pricing, multicurrency, PDF invoice, WooCommerce bridge, etc.)—mostly booleans via filters/settings.
- Health-style hints (e.g. renewal timing, version mismatch flags)—as provided by Pro filters, without customer data.
Support & stability hints (“support” block)
Coarse technical risk flags, for example:
- Counts of recent cron failures / REST errors (as tracked locally by Yatra).
- Plugin conflict candidates: only known plugin file paths from a fixed candidate list (e.g. certain travel/commerce plugins) if those plugins are active—not your full plugin list here.
- Memory / PHP / WordPress version risk booleans (e.g. low PHP memory limit, old PHP, very old WP).
- Checkout misconfiguration (boolean via filter).
Product events (events)
Anonymous counters for named events since the last reset, for example:
onboarding_started,onboarding_completedfirst_booking_received,first_trip_createdpayment_gateway_connectedsetup_abandoned- Other keys recorded via
record_event/yatra_usage_track_event(increment-only counters).
These are counts and keys, not payloads of user actions.
Full plugin, theme, and module inventory (warehouse sync)
When telemetry is sent to a MantraBrain-style warehouse, the payload may also include:
Active plugins (and must-use plugins)
For each active plugin (except the main Yatra row, which is represented as the product): slug, name, version, and the plugin file path (e.g. folder/plugin.php).
Themes
Active theme and parent theme (if child theme): slug, name, version, stylesheet identifier, role (active vs parent).
Yatra internal modules
Each module: slug, name, enabled/available/requires Pro flags.
This inventory is software inventory, not visitor or booking data.
Your choices
- You can turn usage telemetry off at any time in Yatra → Settings → Advanced → Usage tracking .
- When disabled, no further telemetry sends are scheduled from Yatra for this purpose.