How to Test Your Singular SDK Integration

Testing Singular SDK Integration

Comprehensive guide for validating Singular SDK and S2S integrations using Testing Console, Export Logs, and SDK Audit reports before production release.

After integrating Singular SDK into your app or building server-to-server integration, verifying data transmission to Singular is essential before production release.

Target Audience Developers, QA Engineers
Prerequisites
  • Singular SDK or S2S integration implemented in app
  • Mobile device for Testing Console validation
  • Test environment configured with SDK/Secret keys

Testing Tools Overview

Available Testing Methods

Singular provides three complementary tools for integration validation, each serving specific testing phases and requirements.

Tool Purpose Timing Best For
Testing Console Stream live real-time data from test devices for immediate feature validation during implementation Real-time Active development and debugging
Export Logs Download user-level data for detailed analysis and verification after testing ~3 hour delay Historical data analysis
SDK Audit Automatically identify integration issues with actionable recommendations for resolution Last 3 days data Comprehensive validation

Testing Strategy: Use Testing Console during active development for immediate feedback, Export Logs for detailed verification, and SDK Audit for final comprehensive validation before production release.


Testing Console

Real-time testing tool streaming live data from registered test devices for immediate integration validation and debugging.

Prerequisites

Before Using Testing Console

Ensure following requirements met before starting Testing Console validation:

  • Clean Test Device: Use device that never had test application installed for accurate install attribution testing
  • Event Test Plan: Prepare list of events and attributes to verify during testing session
  • iOS ATT Awareness: Determine whether App Tracking Transparency (ATT) prompt appears, affecting identifier type (IDFV vs IDFA) for testing

Important Limitation: Testing Console does not provide historical reports. Events must occur while device is selected and 🟢 Live indicator active to appear in console.


Step 1: Add Test Device

Device Registration

Register test device in Testing Console using appropriate device identifier for real-time event streaming.

How to Add Device
#

Registration Steps

  1. Navigate to Developer Tools → Testing Console in Singular platform
  2. Click Add Device button
  3. Select Device Type from dropdown:
    • Android: Prefer Google Advertising ID (GAID/aifa), AppSetID (asid), or AndroidID (andi) in that order
    • iOS: Use IDFA when available (requires ATT consent), otherwise use IDFV
  4. Enter Device ID captured from device
  5. Provide distinctive Device Name for easy identification
  6. Click Save Device to complete registration

Add Device to Testing Console

Capturing Device Identifiers
#

Android Device Identifiers

Recommended Method: Use Singular Device Assist app (Android) to retrieve GAID/aifa.

Alternative Method: Enable Singular SDK logging and capture identifier from Android LogCat:

SingularConfig config = new SingularConfig(SdkKey, SdkSecret)
    .withLoggingEnabled()
    .withLogLevel(1);

Sample LogCat Output:

2023-06-01 15:48:32.224 27442-27560/com.singular.test D/Singular: DeviceInfo [worker] - andi : 8868adc2f7ffffff
2023-06-01 15:48:32.224 27442-27560/com.singular.test D/Singular: DeviceInfo [worker] - asid : 12dc3652-5e46-f2bb-a93a-b3c092ffffff
2023-06-01 15:48:32.224 27442-27560/com.singular.test D/Singular: DeviceInfo [worker] - aifa : 3bbc76b0-cebb-4a9f-b6ec-10ca1affffff

iOS Device Identifiers

IDFA Capture: Use when ATT framework implemented and tracking authorized.

Method 1: Singular Device Assist app (iOS) - grant tracking permission when prompted.

Method 2: Log IDFA in Xcode debug console:

SWIFTOBJECTIVE-C
// Example in Swift
print("IDFA", ASIdentifierManager.shared().advertisingIdentifier.uuidString)

IDFV Capture: Use when ATT not implemented or tracking not authorized.

SWIFTOBJECTIVE-C
// Example in Swift
print("IDFV", UIDevice.current.identifierForVendor!.uuidString)

Step 2: Test SDK Initialization

Validate Session Tracking

First validation step confirms SDK properly initialized and communicating with Singular platform by verifying session event transmission.

Critical First Test: Session event represents successful SDK initialization and enables Singular to track attribution. Without session events, attribution cannot function.

Initialization Testing Steps

  1. In Events Log, select device name from Devices dropdown and confirm 🟢 Live indicator visible
  2. Initialize app from testing platform or open app on device
  3. Verify session event appears in Events Log, indicating successful SDK initialization

Session Event in Testing Console


Step 3: Test Integration Features

Feature-Specific Validation

After confirming SDK initialization, validate specific features implemented in integration using Testing Console real-time monitoring.

Test Custom User ID
#

Purpose

Validate custom user ID properly transmitted to Singular for cross-device user tracking and analytics.


Testing Procedure

  1. Register device in Testing Console
  2. Open app on test device
  3. Trigger action that sends user ID (e.g., login) if not sent automatically
  4. Expand event details in Testing Console and verify custom_user_id field contains expected value

Custom User ID in Event Details


Troubleshooting

If custom user ID not appearing:

  • Verify method setting user ID actually called at appropriate time in app flow
  • Add Singular SDK event named "setting_custom_user_id" for visibility in Testing Console
  • Check SDK logs for user ID assignment confirmation
Test Events
#

Purpose

Verify event tracking implementation sends events with correct names and attributes to Singular.


Testing Procedure

For each event implemented in SDK integration:

  1. Trigger event in app and verify event appears in Testing Console with correct name
  2. Click event row to expand details and confirm Event Data section contains expected attributes

Events in Testing Console

Event Data Details


Troubleshooting

If event not appearing:

  • Verify app opened after device completely registered in Testing Console
  • Check Export Logs for event (available after ~3 hour delay)
  • Confirm event triggering code executed properly in app

Additional Resources

Test Revenue
#

Purpose

Validate revenue tracking implementation correctly reports purchase amounts, currency, and additional revenue details.


Testing Procedure

For each revenue event type implemented:

  1. Trigger revenue event in app and verify event appears in Testing Console
  2. Expand event row and confirm following fields present:
    • pcc - Currency code (e.g., USD, EUR)
    • r - Revenue amount
    • Additional revenue event attributes if implemented

Default Revenue Event Name: If revenue event not assigned custom name, appears as __iap__ (default revenue event name).

Revenue Event Details


Additional Resources

Test Deep Linking
#

Purpose

Verify deep linking implementation correctly handles Singular Links and directs users to intended in-app destinations.

Prerequisite: This testing assumes organization using Singular Links for campaign tracking.


1. Set Up Test Destination

  1. Navigate to Settings → Apps in Singular platform
  2. Find app and click to open configuration
  3. Add deep link destination matching destination handler code in SDK integration recognizes

Add Deep Link Destination


2. Create Test Link

  1. Go to Attribution → Manage Links and select app
  2. Click Create Link
  3. Under Link Type, select "Custom Source" and under Source Name, select "Email"
  4. Provide link name
  5. Expand Link Settings and Redirects section
  6. Select test destination from Deep Link dropdown
  7. Enter website URL in Fallback Destination for Other Platforms field
  8. Click Generate and copy link from Click-Through Tracking Link field

Generate Tracking Link


3. Test Link Functionality

  1. Ensure app installed on test device
  2. Email copied link to test device
  3. From device, open email and click link - app should open displaying intended page/content
  4. In Testing Console, verify Deep Link value appears in Session arguments

Deep Link in Session Arguments


Android Testing Alternative

Test Android deep links using ADB (Android Debug Bridge) for command-line validation.

Prerequisites:

  • Install ADB (included in Android SDK platform tools)
  • Enable Developer Options and USB debugging on device
  • Connect device to computer via USB

Test Command:

adb shell am start -W -a android.intent.action.VIEW -d "https://yourdomain.sng.link/xxxxx?_dl=yourapp://deeplink"

Troubleshooting

Issue: Deep link opens new app instance instead of switching to existing instance.

Solution: Add following to activity in AndroidManifest.xml:

android:launchMode="singleTask"

See Google's <activity> documentation for launchMode options.

Test Deferred Deep Linking
#

Purpose

Verify deferred deep linking properly handles links clicked before app installation, directing users to intended destination on first launch.


Testing Procedure

  1. Check session event in Testing Console to confirm deferred deep linking enabled
  2. Set up test destination and link following deep linking steps above
  3. Uninstall app from test device
  4. Reset device Advertising Identifier
  5. Add new identifier to Testing Console
  6. Email deep link to device and click link from device
  7. Link should redirect to app store - install app (for local builds, sideload from Android Studio or Xcode instead of store version)
  8. After installation, open app - should display intended page/content specified in deep link
  9. In Testing Console, verify deferred deep link value appears in first session event

Deferred Deep Linking Enabled

Deferred Deep Link in First Session

Test Uninstall Tracking
#

Purpose

Validate uninstall tracking implementation correctly detects and reports app uninstalls for churn analysis.

Testing Complexity: Uninstall tracking validation more complex than other SDK functions because Singular depends on Google/iOS services to report uninstalls. Cannot see uninstall event in real-time or use Testing Console for validation.


Prerequisites

Before testing, verify:


Testing Procedure

  1. Install app on real device (not emulator)
  2. Open app so install registered with Singular
  3. Uninstall app from device
  4. Verify uninstall event using one of following methods:
    • Export attribution logs and find uninstall event (may take couple days to appear)
    • If postbacks configured to internal BI system, receive postback about uninstall
    • Contact Singular Support or Customer Success Manager for validation assistance

Important: While waiting to validate uninstall event, do not reset device ID or reinstall app - this invalidates test results.


Testing Console Troubleshooting

Common Issues

Why Are No Events Showing Up?
#

Common Causes

If device registered and no events appearing in Events Log, verify following:

  • Live Monitoring Required: Testing Console only shows events live when device selected and 🟢 Live indicator visible. Does not retrieve historical events
  • App Opened: Ensure app opened on test device to generate session event
  • Events Triggered: If testing specific events, ensure triggering actions performed in app
  • Device ID Accuracy: Double-check correct device ID entered in Testing Console
  • Device ID Type: For iOS without ATT prompt, cannot use IDFA - must use IDFV instead
Why Is _InstallReferrer Event Missing?
#

SDK Version 12.0.0+

Starting from Singular SDK 12.0.0, no need to test _InstallReferrer event. Once app pushed to store, SDK places _InstallReferrer data in first session automatically. Only need to verify session appears in Testing Console.


SDK Version <12.0.0>

For older Android SDK versions, still need to check _InstallReferrer event in Testing Console for proper installation attribution.

iOS IDFA Not Appearing in Testing Console
#

Verification Steps

Double-check IDFA accuracy:

  • Use Singular Device Assist app (iOS) with tracking permission granted
  • Log IDFA in Xcode debug console
  • Check Export Logs (after 1+ hour) with "App Tracking Transparency status" field - value 0 (Undetermined) means ATT prompt not shown

Configuration Checks

  1. Device Settings: Verify Settings → Privacy → Tracking shows "Allow Apps to Request to Track" enabled
  2. ATT Prompt: Confirm ATT prompt appeared during testing - if not shown, IDFA not tracked
  3. Reset IDFA: If device used previously, reset advertising identifier via Settings → Privacy → Tracking
  4. SDK Version: Verify latest Singular SDK version integrated correctly
  5. SDK Initialization: Confirm SDK initialized in AppDelegate or SceneDelegate per documentation
  6. Check Errors: Review Xcode console for SDK initialization or tracking errors

If issues persist after following steps, consult Apple ATT documentation or contact Singular integration engineer.

How to Delete Device
#

Deletion Process

  1. Click Edit icon next to device in Testing Console
  2. In sidebar that appears, click Delete Device
  3. Deletion clears all event logs and removes device's attribution data from Singular

See also: How to reset device for install attribution testing

How to Reset Device for Retesting
#

Reset Requirements

To re-test SDK integration with same device, remove locally cached data from device and clear device's attribution in Singular platform.


Android Reset Steps

  1. Close app and confirm not running (use Force Stop if available)
  2. Go to Settings menu
  3. Navigate to Apps, long press on app, select App Info
  4. Select Storage and click Clear Cache and Clear Data
  5. In Testing Console, select device and click Edit icon, then Delete Device to remove attribution

Device Dropdown

Delete Device


iOS Reset Steps

  1. Close app and uninstall from device
  2. In Testing Console, find device and click Edit icon, then Delete Device to remove attribution

Re-engagement Testing: Test devices (with eye icon enabled in Testing Console) exempted from inactivity window requirement, enabling easier re-engagement attribution testing without waiting for inactivity period.

How to Read Events Log
#

Events Log Interface

After registering device and sending events, events appear in Testing Console Events Log with real-time updates.

Events Log


Event Details

Click event row to expand and view complete event details as sent from app, including all parameters and attributes.

Event Details

iOS TestFlight Limitation: Testing Console does not support iOS TestFlight apps. TestFlight builds reset IDFV on every launch, preventing live event capture.


Export Logs

Download user-level data for detailed integration validation after testing with approximately 1-hour delay from event occurrence.

Export Logs Overview

Purpose and Timing

Export Logs feature enables manual download of user-level data including conversions (installs), events, sessions, and attribution details for comprehensive integration verification.

Best Practices:

  • Date Selection: Double-check Date, App, and Site selected appropriately before downloading data
  • Data Delay: Export Logs data approximately 3 hours behind real-time - allow sufficient time after testing before validation
  • Documentation: For complete Export Logs usage instructions, see Export Logs and User-Level Data FAQ

Using Export Logs

Data Retrieval Process

  1. Navigate to Attribution → Export Logs in Singular platform
  2. Select date range covering testing period
  3. Choose app and site for data export
  4. Select data type (Conversions, Events, Sessions, etc.)
  5. Configure columns to include relevant fields for validation
  6. Click Download to receive CSV file with user-level data

Validation Use Cases

What to Verify

  • Event Tracking: Confirm all triggered events appear with correct names and timestamps
  • Event Attributes: Verify event attributes transmitted correctly with expected values
  • Revenue Tracking: Validate revenue amounts, currency codes, and purchase details
  • Custom User ID: Check custom user ID properly associated with device
  • Device Identifiers: Verify correct device identifier (IDFA, IDFV, GAID) captured
  • Attribution Data: Confirm attribution source and campaign parameters correct

SDK Audit Report

Automated integration validation tool identifying implementation issues with actionable recommendations for resolution before production release.

SDK Audit Overview

Purpose and Scope

SDK Audit Report analyzes data received from apps in last 3 days, automatically detecting integration issues and providing troubleshooting guidance.

Audit Checks:

  • Session Tracking: Verifies app reporting user sessions (fundamental SDK/S2S functionality enabling attribution)
  • Event Tracking: Confirms app reporting in-app events and revenue correctly
  • Revenue Best Practices: Validates revenue tracking follows recommended implementation patterns
  • Deferred Deep Linking: Checks DDL enablement status
  • Optional Features: Identifies missing optional features that may enhance tracking capabilities

Running SDK Audit

Audit Execution Steps

1

Execute Audit Report

  1. Navigate to Developer Tools → Testing Console
  2. Click Run Audit button in top right corner
  3. Wait for audit to complete analysis (typically few minutes)

Run SDK Audit

2

Review and Resolve Issues

  1. Download completed audit report in CSV format
  2. Review list of identified issues across all apps and platforms
  3. Prioritize fixes based on issue type (Error, Warning, Info) and feature relevance
  4. Follow recommendations in Error Description field to resolve issues

Issue Prioritization: Not all issues critical or relevant depending on implemented features. Review Validation Name to determine if optional feature you chose not to implement - if so, can safely ignore error message.


Understanding Audit Report

Report Structure

SDK Audit Report presents list of integration issues with contextual information for troubleshooting and resolution.

SDK Audit Report Structure

Column Description
App Name App name as configured in Singular platform
App Bundle App bundle identifier (e.g., com.example.appname)
Platform iOS, Android, or Amazon
App Version App version number if available
Validation Name Integration area where issue found (e.g., "Custom user ID", "Revenue events")
Type

Issue severity level:

  • Error: Critical issue preventing integration from functioning - must fix before production release (e.g., no user sessions received)
  • Warning: Integration works but violates best practices - should fix for optimal tracking (e.g., missing custom user ID)
  • Info: Optional functionality not implemented - may be intentional based on requirements (e.g., DDL not enabled)
Error Description Detailed issue information and recommended resolution steps

Issue Resolution Guidelines

Priority Levels

Error-Type Issues (Critical)
#

Resolution Priority

Must resolve before production release - these issues prevent core functionality.


Common Error Issues

  • No Sessions Received: SDK not initialized or not sending data to Singular
  • Invalid SDK Keys: Incorrect SDK key or secret configured
  • Platform Mismatch: App reporting wrong platform identifier

Resolution Approach

  1. Review Error Description for specific guidance
  2. Consult SDK integration guide for affected platform
  3. Verify SDK configuration and initialization code
  4. Re-test using Testing Console after fixes
  5. Run new SDK Audit to confirm resolution
Warning-Type Issues (Recommended)
#

Resolution Priority

Should resolve for best practices - integration functions but improvements recommended.


Common Warning Issues

  • No Custom User ID: Custom user ID not implemented for cross-device tracking
  • Revenue Tracking Issues: Revenue events not following best practices
  • Missing Event Attributes: Events tracked without recommended attributes

Resolution Approach

  1. Assess business impact of missing feature
  2. Review implementation documentation for feature
  3. Implement if feature aligns with requirements
  4. Test implementation using Testing Console
Info-Type Issues (Optional)
#

Resolution Priority

Review and decide - optional features that may not apply to specific use case.


Common Info Issues

  • Deferred Deep Linking Disabled: DDL may not be relevant to marketing strategy
  • Uninstall Tracking Not Configured: Uninstall tracking optional based on requirements
  • Optional SDK Features: Additional features not critical for basic functionality

Resolution Approach

  1. Review Validation Name to identify optional feature
  2. Determine if feature relevant to business requirements
  3. If not relevant, safely ignore issue
  4. If relevant, implement following SDK documentation

Additional Resources

Complete documentation for SDK integration, testing, and troubleshooting.

Related Documentation