Push Notification Tracking

Last Updated: July 2, 2026
Audience: Client developers integrating Zixflow SDK (Flutter)
Purpose: Track push notification lifecycle events — delivery, open, and action clicks — so Zixflow can measure campaign performance accurately. See also: Push Notifications and the reference implementation push_handlers.dart.

Why Push Tracking Matters

When Zixflow sends a push notification to a user’s device, it records that the notification was sent. But it cannot know on its own:

Did the notification actually arrive on the device?
Did the user open it (tap the banner)?
Did the user tap an action button (“Shop Now”, “Remind Me”)?

Your app reports these three moments back to Zixflow using the SDK. This powers the delivery analytics you see in campaign dashboards — open rates, click rates, and conversion funnels after a push.

The Delivery Lifecycle at a Glance

Zixflow Campaign ──sends──▶ Zixflow (via FCM/APNs) ──delivers──▶ Device OS
                                                                │
                                                     ┌──────────┴──────────┐
                                                     │                     │
                                               App foreground        App background
                                               onMessage()           onMessageOpenedApp()
                                                     │                     │
                                            Your app calls:          Your app calls:
                                         trackMetric(delivered)   trackMetric(opened)
                                                     │
                                          User taps action button
                                                     │
                                             Your app calls:
                                        track("Push Notification
                                           Action Clicked")

Each of these SDK calls results in a delivery report event flowing to the Zixflow backend, updating the campaign’s live metrics.

The Push Payload

Zixflow injects two special fields into every push notification’s data payload. Your app uses these to associate the tracking event with the correct campaign delivery.

Field	Example value	Purpose
`Zixflow-Delivery-ID`	`"626533406292836846"`	Unique ID for this delivery (matches campaign record)
`Zixflow-Delivery-Token`	`"dcFRlDhiRbehM1vg-Lx_yn:..."`	The FCM/APNs token the notification was sent to

These appear inside message.data (Flutter/Android) or userInfo (iOS native). The SDK’s trackMetric() method requires both to route the event correctly. Example raw data payload received by the app:

{
  "Zixflow-Delivery-ID": "626533406292836846",
  "Zixflow-Delivery-Token": "dcFRlDhiRbehM1vg...",
  "title": "Flash Sale! 70% OFF 🔥",
  "body": "Limited time only — grab your deal now!",
  "deeplink_url": "https://yourapp.com/sale",
  "image_url": "https://cdn.yourapp.com/banner.png",
  "large_icon_url": "https://cdn.yourapp.com/icon.png",
  "badge": "5",
  "action_buttons": "[{\"name\":\"Shop Now\",\"deeplink\":\"https://yourapp.com/sale\"},{\"name\":\"Remind Me\",\"deeplink\":\"\"}]",
  "notif_id": "626533406292836846"
}

Important: action_buttons is a JSON string (not a nested object). Parse it with json.decode() / JSONSerialization before use.

The Three Tracking Events

Each interaction maps to a specific SDK call. The event name, parameters, and platform code are listed for each below.

1. Delivery Confirmed

Event name (sent to Zixflow): Push Notification Delivered
When to fire: The moment the push data payload arrives on the device — inside your onMessage / onMessageReceived / willPresent handler.
SDK method: Zixflow.instance.trackMetric(deliveryID:, deviceToken:, event: MetricEvent.delivered)
What happens: Zixflow updates the campaign delivery record to delivered. No profile event is stored. Parameters:

Parameter	Required	Description
`deliveryID`	✅	Value of `Zixflow-Delivery-ID` from the push payload
`deviceToken`	✅	Value of `Zixflow-Delivery-Token` from the push payload (or your cached FCM/APNs token)
`event`	✅	`MetricEvent.delivered`

FirebaseMessaging.onMessage.listen((RemoteMessage message) {
  final deliveryId    = message.data['Zixflow-Delivery-ID'] ?? '';
  final deliveryToken = message.data['Zixflow-Delivery-Token'] ?? fcmToken ?? '';

  if (deliveryId.isNotEmpty && deliveryToken.isNotEmpty) {
    Zixflow.instance.trackMetric(
      deliveryID:  deliveryId,
      deviceToken: deliveryToken,
      event:       MetricEvent.delivered,
    );
  }
});

2. Notification Opened

Event name (sent to Zixflow): Push Notification Opened
When to fire: When the user taps the notification banner. Fire for both body taps and action button taps.
SDK method: Zixflow.instance.trackMetric(deliveryID:, deviceToken:, event: MetricEvent.opened)
What happens: Zixflow updates the campaign delivery record to opened. No profile event is stored. Parameters:

Parameter	Required	Description
`deliveryID`	✅	Value of `Zixflow-Delivery-ID` from the push payload
`deviceToken`	✅	Value of `Zixflow-Delivery-Token` from the push payload
`event`	✅	`MetricEvent.opened`

// Background tap — app was backgrounded
FirebaseMessaging.onMessageOpenedApp.listen((RemoteMessage message) {
  final deliveryId    = message.data['Zixflow-Delivery-ID'] ?? '';
  final deliveryToken = message.data['Zixflow-Delivery-Token'] ?? fcmToken ?? '';

  if (deliveryId.isNotEmpty && deliveryToken.isNotEmpty) {
    Zixflow.instance.trackMetric(
      deliveryID:  deliveryId,
      deviceToken: deliveryToken,
      event:       MetricEvent.opened,
    );
  }
});

// Terminated tap — app was closed when user tapped
bool _initialHandled = false;
final initial = await FirebaseMessaging.instance.getInitialMessage();
if (initial != null && !_initialHandled) {
  _initialHandled = true;
  final deliveryId    = initial.data['Zixflow-Delivery-ID'] ?? '';
  final deliveryToken = initial.data['Zixflow-Delivery-Token'] ?? fcmToken ?? '';

  if (deliveryId.isNotEmpty && deliveryToken.isNotEmpty) {
    Zixflow.instance.trackMetric(
      deliveryID:  deliveryId,
      deviceToken: deliveryToken,
      event:       MetricEvent.opened,
    );
  }
}

3. Action Button Clicked

Event name (sent to Zixflow): Push Notification Action Clicked
When to fire: When the user taps a named action button (“Shop Now”, “Try It Free”, etc.). Always fire trackMetric(opened) first, then fire this event.
SDK method: Zixflow.instance.track(name: "Push Notification Action Clicked", properties: {...})
What happens: Zixflow records a clicked delivery report and captures which button was tapped for campaign analytics.

This is a named track() call — not trackMetric(). There is no MetricEvent enum for clicks.

Properties:

Property	Type	Required	Description
`Zixflow-Delivery-ID`	string	✅	Links this event to the campaign delivery record
`action_index`	integer	✅	0-based index of the button tapped (`0` = first button)
`action_name`	string	✅	Human-readable button label (e.g. `"Shop Now"`)
`Zixflow-Delivery-Token`	string	Recommended	Token push was sent to
`action_deeplink`	string	Recommended	URL the button navigates to
`title`	string	Optional	Notification title
`action_id`	string	Optional	OS-level action identifier (e.g. `"ACTION_0"`)
`source`	string	Optional	`"local_notification"` or `"web_push"`

// In FlutterLocalNotificationsPlugin.initialize()
onDidReceiveNotificationResponse: (NotificationResponse response) {
  final payload = jsonDecode(response.payload ?? '{}') as Map<String, dynamic>;

  // Always fire opened first
  final deliveryId    = payload['Zixflow-Delivery-ID'] ?? '';
  final deliveryToken = payload['Zixflow-Delivery-Token'] ?? '';
  if (deliveryId.isNotEmpty && deliveryToken.isNotEmpty) {
    Zixflow.instance.trackMetric(
      deliveryID: deliveryId, deviceToken: deliveryToken, event: MetricEvent.opened,
    );
  }

  // Then fire action clicked (only if a button was tapped, not body tap)
  if (response.actionId != null) {
    final actionIndex = int.tryParse(response.actionId!.replaceAll(RegExp(r'\D'), '')) ?? -1;
    final buttons     = _parseButtons(payload['action_buttons']);
    final actionName  = (actionIndex >= 0 && actionIndex < buttons.length)
        ? buttons[actionIndex]['name'] ?? 'Action ${actionIndex + 1}'
        : 'Action ${actionIndex + 1}';

    Zixflow.instance.track(
      name: 'Push Notification Action Clicked',
      properties: {
        'Zixflow-Delivery-ID':    deliveryId,
        'Zixflow-Delivery-Token': deliveryToken,
        'action_index':           actionIndex,
        'action_name':            actionName,
        'action_deeplink':        actionIndex >= 0 ? (buttons[actionIndex]['deeplink'] ?? '') : '',
      },
    );
  }
},

Platform-Specific Integration

Flutter is the reference implementation. The pattern is the same for both platforms once FCM / APNs tokens are obtained.

Step 1 — Register Device Token

import 'package:zixflow/zixflow.dart';
import 'package:firebase_messaging/firebase_messaging.dart';

// On app start, get the FCM token and register it
final fcmToken = await FirebaseMessaging.instance.getToken();
if (fcmToken != null) {
  Zixflow.instance.registerDeviceToken(deviceToken: fcmToken);
}

// Keep token fresh — re-register whenever FCM rotates it
FirebaseMessaging.instance.onTokenRefresh.listen((newToken) {
  Zixflow.instance.registerDeviceToken(deviceToken: newToken);
});

Step 2 — Track Delivery (Foreground)

When the app is in the foreground, FCM delivers the message to onMessage. Track delivery immediately.

FirebaseMessaging.onMessage.listen((RemoteMessage message) {
  final deliveryId    = message.data['Zixflow-Delivery-ID'] ?? '';
  final deliveryToken = message.data['Zixflow-Delivery-Token'] ?? fcmToken ?? '';

  if (deliveryId.isNotEmpty && deliveryToken.isNotEmpty) {
    Zixflow.instance.trackMetric(
      deliveryID:  deliveryId,
      deviceToken: deliveryToken,
      event:       MetricEvent.delivered,
    );
  } else {
    // Fallback: no Zixflow IDs present (non-Zixflow push source)
    Zixflow.instance.track(
      name: 'Push Notification Delivered',
      properties: {
        'notification_id': message.messageId ?? '',
        'title': message.notification?.title ?? message.data['title'] ?? '',
        'body':  message.notification?.body  ?? message.data['body']  ?? '',
      },
    );
  }

  // Show a local notification (since app is in foreground)
  _showLocalNotification(message);
});

Step 3 — Track Open (Background / Terminated)

// Background: app was in background, user tapped banner
FirebaseMessaging.onMessageOpenedApp.listen((RemoteMessage message) {
  _trackOpened(message.data, fcmToken);
  _handleDeeplink(message.data['deeplink_url']);
});

// Terminated: app was closed, notification tap launched the app
final initial = await FirebaseMessaging.instance.getInitialMessage();
if (initial != null) {
  _trackOpened(initial.data, fcmToken);
  _handleDeeplink(initial.data['deeplink_url']);
}

void _trackOpened(Map<String, String> data, String? fallbackToken) {
  final deliveryId    = data['Zixflow-Delivery-ID'] ?? '';
  final deliveryToken = data['Zixflow-Delivery-Token'] ?? fallbackToken ?? '';

  if (deliveryId.isNotEmpty && deliveryToken.isNotEmpty) {
    Zixflow.instance.trackMetric(
      deliveryID:  deliveryId,
      deviceToken: deliveryToken,
      event:       MetricEvent.opened,
    );
  } else {
    Zixflow.instance.track(
      name: 'Push Notification Opened',
      properties: {
        'notification_id': data['notif_id'] ?? '',
        'deeplink':        data['deeplink_url'] ?? '',
      },
    );
  }
}

Step 4 — Track Action Button Click (Local Notification Response)

For foreground-received notifications displayed as local notifications, handle taps via flutter_local_notifications:

// In FlutterLocalNotificationsPlugin.initialize()
onDidReceiveNotificationResponse: (NotificationResponse response) {
  final payload = jsonDecode(response.payload ?? '{}') as Map<String, dynamic>;

  if (response.actionId == null) {
    // Body tap → opened
    _trackOpened(payload, null);
  } else {
    // Action button tap → opened + clicked
    _trackOpened(payload, null);

    final actionIndex = int.tryParse(
        response.actionId!.replaceAll(RegExp(r'\D'), '')) ?? -1;
    final buttons = _parseButtons(payload['action_buttons']);
    final buttonName = (actionIndex >= 0 && actionIndex < buttons.length)
        ? buttons[actionIndex]['name'] ?? 'Action ${actionIndex + 1}'
        : 'Action ${actionIndex + 1}';

    Zixflow.instance.track(
      name: 'Push Notification Action Clicked',
      properties: {
        'Zixflow-Delivery-ID':    payload['Zixflow-Delivery-ID'] ?? '',
        'Zixflow-Delivery-Token': payload['Zixflow-Delivery-Token'] ?? '',
        'notification_id':        payload['Zixflow-Delivery-ID'] ?? '',
        'title':                  payload['title'] ?? '',
        'action_id':              response.actionId!,
        'action_index':           actionIndex,
        'action_name':            buttonName,
        'action_deeplink':        _resolveButtonDeeplink(buttons, actionIndex),
        'source':                 'local_notification',
      },
    );
  }
},

List<Map<String, dynamic>> _parseButtons(dynamic raw) {
  if (raw == null) return [];
  try {
    final decoded = raw is String ? jsonDecode(raw) : raw;
    return List<Map<String, dynamic>>.from(decoded as List);
  } catch (_) {
    return [];
  }
}

Action Buttons Format

The action_buttons field in the push payload is a JSON-encoded string containing an array of button objects. You must parse it before use. Payload value (raw string):

"[{\"name\":\"Shop Now\",\"deeplink\":\"https://yourapp.com/sale\"},{\"name\":\"Remind Me\",\"deeplink\":\"\"}]"

Parsed structure:

[
  { "name": "Shop Now",  "deeplink": "https://yourapp.com/sale" },
  { "name": "Remind Me", "deeplink": "" }
]

Rules:

Maximum 2 buttons per notification (iOS system limit; Android supports more but keep it consistent)
deeplink may be an empty string — handle gracefully, don’t navigate to a blank URL
Button index is 0-based — button at index 0 is leftmost/first
On iOS, button labels are pre-registered at app init due to OS constraints. Only the deeplinks are dynamic from the payload. Use generic labels in the pre-registration (“Action 1”, “Action 2”) and rely on the action_name in the tracking event for analytics.

iOS pre-registration example (required):

// Must be done at app launch in AppDelegate / UNUserNotificationCenter setup
let actions = [
    UNNotificationAction(identifier: "ACTION_0", title: "Action 1", options: .foreground),
    UNNotificationAction(identifier: "ACTION_1", title: "Action 2", options: .foreground),
]
let category = UNNotificationCategory(identifier: "ZX_2BTN", actions: actions,
                                       intentIdentifiers: [], options: [])
UNUserNotificationCenter.current().setNotificationCategories([category])

Parsing `action_buttons`

/// Parses the Zixflow `action_buttons` payload (JSON string or already-decoded list).
List<Map<String, dynamic>> parseActionButtons(dynamic raw) {
  if (raw == null) return [];
  try {
    final decoded = raw is String ? jsonDecode(raw) : raw;
    return List<Map<String, dynamic>>.from(decoded as List);
  } catch (e) {
    return [];
  }
}

Building the Buttons on the Notification (Foreground Path)

// push_handlers.dart pattern
final buttons = parseActionButtons(data['action_buttons']);
final androidActions = <AndroidNotificationAction>[];
for (var i = 0; i < buttons.length && i < 2; i++) {
  androidActions.add(
    AndroidNotificationAction(
      'ACTION_$i',
      buttons[i]['name']?.toString() ?? 'Action ${i + 1}',
      showsUserInterface: true,
    ),
  );
}

final androidDetails = AndroidNotificationDetails(
  channelId,
  channelName,
  importance: Importance.high,
  priority: Priority.high,
  actions: androidActions,     // ← dynamic buttons attached here
);

// iOS buttons are pre-registered (see category above) — deeplinks/names for tracking
// come from the payload at tap time, not from anything attached here. Just make sure
// `categoryIdentifier: 'ZX_2BTN'` is set on the iOS notification details so the OS
// shows the pre-registered actions:
final iosDetails = DarwinNotificationDetails(
  categoryIdentifier: 'ZX_2BTN',
);

onDidReceiveNotificationResponse’s response.actionId (e.g. "ACTION_0") is what you parse back into an index for tracking.

Handling the Tap (End-to-End)

Platform	Callback	Identifier format	Resolve to index
Flutter	`onDidReceiveNotificationResponse`	`response.actionId` = `"ACTION_0"` / `"ACTION_1"`	`int.parse(actionId.replaceAll(RegExp(r'\D'), ''))`

Important on Android (Flutter): pressing an action button does not automatically dismiss the notification the way tapping the notification body does — see Sticky Notifications below.

Sticky Notifications

Field: sticky (boolean, sent in the data.* payload as the string "true" / "false") “Sticky” means the notification survives passive dismissal — the user swiping it away, or hitting “Clear all” — the kind of behavior used for downloads-in-progress, active calls, or ongoing music playback. It does not mean the notification is permanently stuck: tapping the notification body or an action button always removes it, exactly like a normal notification. This is Android-only — there is no iOS/APNs equivalent (iOS notifications can always be swiped away, with no API to change that), so all iOS code paths below are a deliberate no-op for this field.

This requires two separate Android notification flags, not one — and a third piece of manual cleanup for action buttons.

setAutoCancel(true) must always be on, regardless of sticky — this is what makes tapping the notification body remove it.

setOngoing(true), driven by sticky, is what actually blocks swipe and “Clear all”.

Action buttons need an explicit cancel call in your action handler. Android does not auto-dismiss a notification when an action button is pressed.

Mechanism	Controls	Value
`autoCancel`	Dismissal on body tap	Always `true`
`ongoing`	Dismissal by swipe and “Clear all”	`sticky` — `true` removes the swipe-to-dismiss ‘X’ and excludes it from “Clear all”
Explicit cancel call in your action-button handler	Dismissal on action button press	Always called — not tied to `sticky` at all

final sticky = data['sticky']?.toString() == 'true';

final androidDetails = AndroidNotificationDetails(
  channelId,
  channelName,
  importance: Importance.high,
  priority: Priority.high,
  autoCancel: true,   // always true — body tap always dismisses
  ongoing: sticky,    // true = survives swipe + "Clear all"
);

// In onDidReceiveNotificationResponse, after tracking the action click:
if (response.actionId != null && response.actionId!.isNotEmpty) {
  // Required regardless of `sticky` — action buttons never auto-dismiss on Android.
  if (response.id != null) {
    FlutterLocalNotificationsPlugin().cancel(response.id!);
  }
}

Unlike native Android, Flutter’s Zixflow SDK does not intercept messages with its own background service — your app’s FirebaseMessaging.onMessage / onBackgroundMessage handler is what builds the local notification, so this flag must be read and applied in your own app code.

Deep Link Handling

Every Zixflow push notification may carry a deeplink_url at the top level and per-button deeplinks in action_buttons. Your app is responsible for routing these to the right in-app screen, falling back to an external browser/app when the link isn’t one of your own screens. Priority order for navigation on tap:

If an action button was tapped → use action_buttons[index].deeplink
If body was tapped → use deeplink_url
If neither is set → open app to default screen

Resolution order your routing code should follow, regardless of platform:

Try to resolve the link to one of your app’s own screens (e.g. a custom yourapp:// scheme, or https://yourapp.com/... paths you own).
If it doesn’t match anything you own, fall back to opening it externally (browser, another installed app, mailto:, etc.).
If the URL is empty/missing, do nothing (or navigate to a default/home screen).

// navigation.dart — resolve in-app first, caller falls back externally
bool resolveInAppRoute(String? deeplink) {
  if (deeplink == null || deeplink.isEmpty) return false;
  final uri = Uri.tryParse(deeplink);
  if (uri == null || uri.scheme != 'zixflowdemo') return false;

  switch (uri.host) {
    case 'sale':
      navigatorKey.currentState?.pushNamed('/sale');
      return true;
    case 'dashboard':
      navigatorKey.currentState?.pushNamed('/dashboard');
      return true;
    default:
      return false;
  }
}

// push_handlers.dart — called from onMessageOpenedApp / getInitialMessage / action tap
void _handleDeeplink(String? url) {
  if (url == null || url.isEmpty) return;
  if (resolveInAppRoute(url)) return;   // handled by one of our own screens

  final uri = Uri.tryParse(url);
  if (uri != null) launchUrl(uri);      // fall back to external browser/app
}

Decision Flowchart

Use this when deciding which SDK call to make for any notification interaction:

Notification received?
├── YES → trackMetric(delivered)        [always, as soon as data payload arrives]
│
User interacted?
├── Tapped notification body
│   └── trackMetric(opened)             [SDK call with deliveryID + deviceToken]
│       └── Navigate to deeplink_url
│
└── Tapped action button
    ├── trackMetric(opened)             [still track opened]
    └── track("Push Notification Action Clicked")  [with action_index + action_name]
        └── Navigate to button's deeplink

Fallback Behaviour (No Zixflow-Delivery-ID)

If the push notification was sent by a non-Zixflow source (e.g., a direct FCM API call, a test tool, or a third-party system), Zixflow-Delivery-ID and Zixflow-Delivery-Token will be absent from the payload. In this case, skip trackMetric(). Push notification event names (Push Notification Delivered, Push Notification Opened, Push Notification Action Clicked) are reserved for Zixflow’s delivery pipeline — they are not stored as user profile events. If you want to track a non-Zixflow push for your own analytics (e.g., to build a custom funnel), use a custom event name instead:

// Use a custom event name — push system events are not stored as profile events
Zixflow.instance.track(
  name: 'External Push Received',   // choose a name that makes sense for your use case
  properties: {
    'notification_id': message.messageId ?? '',
    'title':           message.notification?.title ?? '',
    'body':            message.notification?.body ?? '',
    'source':          'external',
  },
);

Background Isolate Taps

When the app was terminated and the user taps a local notification, the response may run in a background isolate. Re-initialize Zixflow before tracking:

@pragma('vm:entry-point')
Future<void> _notificationTapBackground(NotificationResponse response) async {
  await Zixflow.initialize(
    config: ZixflowConfig(apiKey: 'YOUR_API_KEY'),
  );
  _handleNotificationResponse(response);
}

Wire this as onDidReceiveBackgroundNotificationResponse when initializing FlutterLocalNotificationsPlugin.

Testing Push Tracking

final config = ZixflowConfig(
  apiKey: 'YOUR_API_KEY',
  logLevel: LogLevel.debug,
);

In the dashboard: Messaging → Push Notifications → check Delivered, Opened, and Clicked (action) for your campaign.

Getting Started

Features

Advanced

Reference

Push Notification Tracking

Why Push Tracking Matters

The Delivery Lifecycle at a Glance

The Push Payload

The Three Tracking Events

1. Delivery Confirmed

2. Notification Opened

3. Action Button Clicked

Platform-Specific Integration

Step 1 — Register Device Token

Step 2 — Track Delivery (Foreground)

Step 3 — Track Open (Background / Terminated)

Step 4 — Track Action Button Click (Local Notification Response)

Action Buttons Format

Parsing `action_buttons`

Building the Buttons on the Notification (Foreground Path)

Handling the Tap (End-to-End)

Sticky Notifications

Deep Link Handling

Decision Flowchart

Fallback Behaviour (No Zixflow-Delivery-ID)

Background Isolate Taps

Testing Push Tracking

​Why Push Tracking Matters

​The Delivery Lifecycle at a Glance

​The Push Payload

​The Three Tracking Events

​1. Delivery Confirmed

​2. Notification Opened

​3. Action Button Clicked

​Platform-Specific Integration

​Step 1 — Register Device Token

​Step 2 — Track Delivery (Foreground)

​Step 3 — Track Open (Background / Terminated)

​Step 4 — Track Action Button Click (Local Notification Response)

​Action Buttons Format

​Parsing action_buttons

​Building the Buttons on the Notification (Foreground Path)

​Handling the Tap (End-to-End)

​Sticky Notifications

​Deep Link Handling

​Decision Flowchart

​Fallback Behaviour (No Zixflow-Delivery-ID)

​Background Isolate Taps

​Testing Push Tracking

Why Push Tracking Matters

The Delivery Lifecycle at a Glance

The Push Payload

The Three Tracking Events

1. Delivery Confirmed

2. Notification Opened

3. Action Button Clicked

Platform-Specific Integration

Step 1 — Register Device Token

Step 2 — Track Delivery (Foreground)

Step 3 — Track Open (Background / Terminated)

Step 4 — Track Action Button Click (Local Notification Response)

Action Buttons Format

Parsing `action_buttons`

Building the Buttons on the Notification (Foreground Path)

Handling the Tap (End-to-End)

Sticky Notifications

Deep Link Handling

Decision Flowchart

Fallback Behaviour (No Zixflow-Delivery-ID)

Background Isolate Taps

Testing Push Tracking