Skip to main content
User activity logs record actions in your service, such as viewing products, searching, adding items to a cart, and making purchases. A2 uses this data to predict users’ product interests and improve ad recommendations. Send user behavior from across your service, beyond responses to ads recommended by A2. Using the same product ID in your catalog and activity logs connects each action to the product’s information. Implement activity logs in the following order.
1

Choose events

Identify the events that apply to your service and send as many relevant actions as you can collect.
2

Build requests

Include user, device, and product IDs, along with the event time.
3

Check delivery

Send events when they happen and review what you can verify about collection.

Before you begin

  • API address: The address of your deployed A2 environment. Sending activity logs does not require an access token.
  • User and device IDs: Identifiers that consistently distinguish the user and device performing an action
  • Product IDs: IDs registered in your catalog
Use the same user_id for the same user across events, and the same string ID for a product in your catalog and activity logs. Do not assign one shared ID to all guests or generate a new user ID for each event.

Send a product view first

This example sends a view event for product 1001. Replace <UNIX_TIME_SECONDS> with the event’s Unix timestamp in seconds, and replace the user, device, and product IDs with real values.
HTTP 200 means the request received a response; it does not confirm collection of an individual event. See the event descriptions below for the type and fields that fit your service, then check your request using Test events.

Supported events

Send as many events as apply to actions in your service. Select an event below to jump to its description and request example.

Common fields

Build each request by adding the event-specific fields to the common fields below.

Event specifications

Send only product IDs in catalogs; register names, images, and other product details through the Catalog API.
When one event contains multiple products in catalogs, DMP learning currently uses only the first product, catalogs[0].id. Do not assume all products in the array contribute to learning.Replace example user, device, and product IDs and timestamp with real values. Event times are integers in seconds.

Product view item_view

Send this event when a user views a product.

Product click item_click

Send this event when a user clicks a product.

Add to cart add_cart

Send this event when a product is added to the cart.

Page view page_view

Send this event when a user views a page. You can identify the page with the common page_id field.
Send this event when a user runs a search. Send the query instead of a product list.

Purchase purchase

Send this event when a purchase is completed. Include the purchased products, amount, and currency.

Waiting wait

Send this event when a user registers through your service’s waiting feature.

Reservation resv

Send this event when a reservation is completed. Include the reserved products, amount, and currency.

Bookmark bmrk

Send this event when a user bookmarks a product.

Item impression item_impression

Send this when products appear in a service list that was not served by A2. Send impressions of A2 recommendations separately as reco_log. catalogs with product id values is required; the zero-based list position is optional.

Checkout checkout

Send this when a user enters checkout before completing a purchase. catalogs with product id values is required. The transaction_id for linking a later purchase and revenue with the anticipated amount and currency are optional.

Purchase or reservation cancellation cancel

Send this when a full or partial cancellation or refund of a purchase or reservation is confirmed. The original purchase or reservation’s transaction_id is required. catalogs for affected products and revenue with the cancelled or refunded amount as a positive number are optional. To connect the events, send the same transaction_id in the original purchase or resv event.

Connect product activity and ad responses

For a user viewing and purchasing product 1001, distinguish these records. Use a consistent value for the same user in ad request user.id and activity log user_id. Also account for DMP learning using only the first product in a multi-product purchase. See Ad Event Tracking for ad event delivery.

Send events through the API

Send events using the Record activity logs API. As in the product-view curl example above, put the JSON body directly in -d '...'.
1

Choose the event body

Select the JSON example for the event you are implementing. Check its schema and event-specific fields, then replace the user, device, and product IDs and the event time with real values.
2

Send the event

Replace the JSON inside -d '...' in the earlier curl example with the selected event body, and use your API address for <A2_API_URL>. HTTP 200 does not guarantee event validity or completed collection and processing, so review the request using the testing section below.
3

Connect delivery to actions in your service

Build and send a request when the actual product view, search, purchase, or other action occurs.You can send from the web or app, or through your server. Preserve consistent user and product IDs and the actual event time across delivery routes, and avoid sending the same action from both routes.
Implement purchase activity logs and ad conversion tracking separately. See Ad Event Tracking to record a conversion as an ad outcome.

Test events

Perform an action once in your service and inspect the corresponding request. A2 currently provides no screen or API for looking up the collection status of an individual activity log. The checks above verify delivery from your service, but cannot independently confirm collection in A2. If you need collection confirmation, provide the test time, schema, request body with sensitive information removed, and HTTP response to your A2 contact.

Next steps

Check catalog, user activity log, and ad tracking delivery in Verification and Troubleshooting.

Common issues

Separate HTTP success from completed collection. Review request fields and types, then contact support with the test information above.
Check for lost leading zeros during numeric ID conversion, or IDs taken from a different system.
Check whether each request generates a new user_id, or your server, web, and app use different values.
Check duplicate handlers, client/server double delivery, and retries. An identical id does not guarantee deduplication.
Check the address, request body, and response status and body. Collection after a timeout is also unknown, so consider duplicate delivery before resending.