Built-In Events Reference
Comprehensive guide to automatically mapped events in Singular SDK and S2S integrations, covering event types, tracking triggers, and reporting locations.
Automatic Event Tracking: When integrating Singular SDK or S2S into your app, certain events are automatically mapped and tracked in Singular platform without additional configuration.
These built-in events appear automatically in user-level reporting, partner postbacks, and aggregate analytics, providing foundational metrics for campaign measurement and user behavior analysis.
Automatic Event Tracking
SDK Initialization Benefits
Once Singular SDK initialized or S2S integration configured, Singular automatically reports core events without requiring additional implementation.
Automatically Tracked Metrics:
- Installs: First session for unique devices tracked automatically
- Sessions: All app launches and user sessions monitored
- DAU: Daily active users calculated from session data
- Retention: User return rates measured across cohorts
Revenue Event Configuration: While install and session events are automatic, revenue events require in-app configuration using SDK revenue methods or S2S revenue parameters. Once configured, revenue tracking is automatic for all subsequent purchases.
Event Reporting Locations
Where Built-In Events Appear
Built-in events automatically appear in multiple reporting and data export locations across Singular platform.
| Location | Description |
|---|---|
| User-Level Attribution Logs |
Export detailed user-level data including all built-in events with timestamps and attribution information. |
| Partner Postbacks |
Send built-in events to partner platforms for campaign optimization if partner configured to receive auto-generated event names. Configure in Partner Configuration → Event Postbacks |
| Internal BI Postbacks |
Forward built-in events to internal business intelligence systems for custom analytics and reporting. |
| SKAN Conversion Models |
Include built-in events in SKAdNetwork conversion value mapping for iOS campaign optimization. Configure in SKAN Conversion Model Builder |
Supported Auto-Mapped Events
Complete reference of built-in events automatically tracked by Singular SDK and S2S integrations with tracking triggers and availability details.
User-Level Event Reference
Built-In Event Types
__START__ - Install Event
Event Description
Represents app installation and first session for unique device, serving as primary install attribution event.
Tracking Trigger
Automatically tracked when first session sent through SDK/S2S integration for unique device identifier.
Important Limitation: __START__
event
visible ONLY in BI Postbacks. This event does not appear
in standard
reporting or partner postbacks.
Technical Details
| Event Name |
__START__
|
| Event Type | Install/First Session |
| Tracking Method | Automatic (SDK/S2S initialization) |
| Configuration Required | None - tracked automatically |
| Availability | BI Postbacks only |
__SESSION__ - Session Event
Event Description
Tracks all app launches and user sessions, providing foundation for engagement and retention metrics.
Tracking Trigger
Automatically tracked when sessions sent through SDK/S2S integration. Includes first session (install) and all subsequent app launches.
Session Definition
Session begins when app brought to foreground and ends after configurable timeout period (default: 60 seconds) when app backgrounded.
Technical Details
| Event Name |
__SESSION__
|
| Event Type | Session/App Launch |
| Tracking Method | Automatic (SDK session management) |
| Configuration Required | None - tracked automatically |
| Availability | All reporting locations |
Usage in Analytics
Session events power multiple derived metrics:
- Daily Active Users (DAU): Unique users with sessions on given day
- Retention Rate: Percentage of users returning for subsequent sessions
- Session Frequency: Average sessions per user over time period
- Re-engagement Attribution: Sessions from re-engagement campaigns
__iap__ - SDK Revenue Event
Event Description
Tracks in-app purchases and revenue events reported through SDK revenue methods without custom event names.
Tracking Trigger
Tracked when SDK/S2S integration reports revenue event through revenue method, provided revenue event does not have custom name in SDK configuration.
Custom Revenue Event Names: If revenue
event configured
with custom name (e.g., "purchase" or "subscription"),
it appears with
that custom name instead of __iap__. Both
approaches track
revenue correctly; __iap__ is default when
no custom name
specified.
Technical Details
| Event Name |
__iap__
|
| Event Type | Revenue/In-App Purchase |
| Tracking Method | SDK revenue method or S2S revenue parameters |
| Configuration Required | Revenue tracking implementation in app code |
| Availability | All reporting locations |
Implementation Examples
iOS SDK:
// Track revenue without custom event name (appears as __iap__)
Singular.revenue(withAmount: 9.99, currency: "USD")Android SDK:
// Track revenue without custom event name (appears as __iap__)
Singular.revenue("USD", 9.99);S2S Revenue:
amt=9.99&cur=USD&is_revenue_event=true__REVENUE__ - Any Revenue Event
Event Description
Aggregate revenue event automatically triggered whenever any type of revenue reported, regardless of revenue source or event name.
Tracking Trigger
Automatically tracked if any revenue reported through any method:
-
__iap__event triggered (default revenue event) - SDK reports ad monetization revenue event
- S2S reports revenue with custom event name (e.g., "purchase")
- Other revenue events like "refund" or "offline_purchase" reported
Postback Configuration Warning
Duplicate Revenue Risk: Do not send
postbacks for
__REVENUE__ if already sending postbacks
for __iap__
or other revenue events. This causes duplicate revenue
reporting as
__REVENUE__ fires for every revenue event.
Recommended Approach: Send postbacks
for specific revenue
events (__iap__, custom revenue events)
OR __REVENUE__,
but not both.
Technical Details
| Event Name |
__REVENUE__
|
| Event Type | Aggregate Revenue (all sources) |
| Tracking Method | Automatic (triggered by any revenue event) |
| Configuration Required | None - automatic when revenue events exist |
| Availability | All reporting locations |
Use Cases
When to Use __REVENUE__:
- Single postback for all revenue types to partner platforms
- Aggregate revenue reporting without event-specific breakdown
- Simplified partner configuration with one revenue event
When to Use Specific Revenue Events:
- Separate tracking for IAP, subscriptions, and ad revenue
- Event-specific optimization in partner platforms
- Detailed revenue attribution by event type
__UNINSTALL__ - Uninstall Event
Event Description
Tracks app uninstalls enabling churn analysis and re-engagement campaign targeting.
Tracking Trigger
Automatically tracked if uninstall tracking enabled for iOS or Android app, and at least one uninstall detected. Once uninstall detected for device, event triggered once daily until reinstall or data retention limit.
Prerequisites
Uninstall tracking must be explicitly enabled in Singular
platform before
__UNINSTALL__ events appear.
Platform-Specific Setup:
Technical Details
| Event Name |
__UNINSTALL__
|
| Event Type | Uninstall/Churn |
| Tracking Method | Automatic (requires uninstall tracking enablement) |
| Configuration Required | Enable uninstall tracking in Singular platform |
| Frequency | Once daily per uninstalled device |
| Availability | All reporting locations (after enablement) |
Uninstall Detection Methods
iOS: Silent push notification verification
Android: FCM (Firebase Cloud Messaging) verification
Detection Timing: Uninstall detection not real-time. Typically detected within 24-48 hours of actual uninstall depending on platform notification delivery.
__REINSTALL__ - Reinstall Event
Event Description
Tracks app reinstallation after previous uninstall, enabling win-back campaign measurement and user lifecycle analysis.
Tracking Trigger
Automatically tracked if uninstall tracking
enabled via
SDK/S2S. When __UNINSTALL__ tracked for device,
then subsequent
__SESSION__ triggered, __REINSTALL__
event
automatically fired.
Trigger Sequence
-
Initial Install: User installs app,
__START__and__SESSION__tracked -
App Usage: User engages with app, multiple
__SESSION__events tracked -
Uninstall: User uninstalls app,
__UNINSTALL__detected and tracked - Reinstall: User reinstalls app and launches
-
Reinstall Detection: First
__SESSION__after__UNINSTALL__triggers__REINSTALL__event
Technical Details
| Event Name |
__REINSTALL__
|
| Event Type | Reinstall/Win-back |
| Tracking Method | Automatic (requires uninstall tracking) |
| Configuration Required | Enable uninstall tracking in Singular platform |
| Prerequisites |
Prior __UNINSTALL__ event for device
|
| Availability | All reporting locations |
Attribution Considerations
Reinstalls can be attributed to re-engagement campaigns if user clicked campaign link before reinstalling. Attribution window settings apply to reinstall attribution same as initial install attribution.
Win-Back Campaign Measurement: Use
__REINSTALL__
events to measure effectiveness of win-back campaigns
targeting churned
users. Compare reinstall rates and subsequent engagement
between campaign
sources.
Aggregated Event Reporting
Singular automatically generates aggregate-level events and metrics based on built-in events, providing campaign performance measurement and user behavior analytics.
Derived Metrics
Session-Based Events
Aggregate metrics automatically calculated from session events appearing in reports and analytics dashboards.
Important Note: These aggregate events not visible in Events section but appear throughout reporting interface as standard metrics.
Metric Definition
Tracks first session for unique devices, representing new app installations and primary attribution metric.
Calculation Method
Count of unique device identifiers with first
__SESSION__
event in reporting period.
Usage in Reporting
- Campaign performance measurement
- Install attribution by source and channel
- Cost per install (CPI) calculation
- Install funnel analysis
Metric Definition
Tracks sessions triggered by re-engagement campaigns, measuring effectiveness of campaigns targeting existing users.
Configuration Dependency
Re-engagement tracking depends on Partner Configuration settings defining re-engagement attribution windows and campaign parameters.
Calculation Method
Sessions attributed to re-engagement campaigns within configured attribution window, regardless of whether first or subsequent session for user.
Usage in Reporting
- Re-engagement campaign ROI measurement
- Dormant user activation rates
- Cross-channel re-engagement performance
- User lifecycle stage transitions
Metric Definition
Daily count of unique users with at least one session on given day, measuring active user base size.
Calculation Method
Count of unique device identifiers with at least one
__SESSION__
event on specific calendar day.
Related Metrics
- WAU: Weekly Active Users (7-day unique user count)
- MAU: Monthly Active Users (30-day unique user count)
- DAU/MAU Ratio: Stickiness indicator (DAU divided by MAU)
Usage in Reporting
- App engagement trend analysis
- User base growth measurement
- Seasonal usage pattern identification
- Platform health monitoring
Metric Definition
Percentage of users who installed app (first session) and returned for additional sessions within specified time period.
Calculation Method
(Users with sessions on Day N after install / Total users installed on Day 0) × 100
Retention Types
| Retention Type | Description |
|---|---|
| Day 1 Retention | Percentage of users returning day after install |
| Day 7 Retention | Percentage of users returning 7 days after install |
| Day 30 Retention | Percentage of users returning 30 days after install |
| Rolling Retention | User returned on or after Day N (cumulative) |
Usage in Reporting
- Product-market fit assessment
- Onboarding effectiveness measurement
- Campaign quality comparison (high vs low retention sources)
- Churn prediction and prevention
Revenue-Based Events
Aggregate Revenue Metrics
Automatically calculated revenue metrics appearing in reports and analytics dashboards for campaign ROI measurement.
Metric Definition
Tracks IAP (in-app purchases), custom revenue events, and subscription revenue, excluding ad monetization.
Included Revenue Sources
-
__iap__events (default revenue event) - Custom revenue events (purchase, subscription, etc.)
- Subscription renewals and upgrades
- One-time purchases and consumables
Excluded Revenue Sources
- Ad monetization revenue (tracked separately in Ad Mon Revenue)
Usage in Reporting
- Campaign ROI and ROAS calculation
- User lifetime value (LTV) measurement
- Monetization funnel analysis
- Revenue attribution by source
Metric Definition
Tracks ONLY revenue generated from ad monetization events, separating advertising income from purchase revenue.
Included Revenue Sources
- Banner ad impressions
- Interstitial ad views
- Rewarded video completions
- Native ad engagements
- Offerwall completions
Implementation Requirement
Requires ad monetization SDK integration or ad revenue reporting via S2S with appropriate event type designation.
Usage in Reporting
- Ad monetization strategy optimization
- Hybrid monetization model analysis
- User segment profitability (IAP vs ad revenue)
- Fill rate and eCPM performance
Metric Definition
Tracks all revenue events from all sources, providing complete monetization picture including IAP, subscriptions, and ad revenue.
Calculation Method
Total Revenue = Revenue + Ad Mon Revenue
Included Revenue Sources
- All IAP and purchase revenue
- Subscription revenue
- Ad monetization revenue
- Custom revenue events (refunds, offline purchases, etc.)
Usage in Reporting
- Complete campaign ROI measurement
- Blended LTV calculation across monetization types
- Overall business performance tracking
- Cross-channel profitability comparison
Revenue Segmentation: Use Revenue, Ad Mon Revenue, and Total Revenue together to understand monetization mix and optimize strategy for different user segments.
Additional Resources
Complete documentation for event tracking, configuration, and reporting in Singular platform.
Event Documentation
- Events FAQ - Complete events reference and frequently asked questions
- How to Track In-App Events - Step-by-step event implementation guide
- Singular Standard Events - Full list of standard events and recommended events by vertical
- Export Logs and User-Level Data FAQ - Accessing user-level event data
- Internal BI Postbacks - Forwarding events to internal systems