# Best Practice

### Send all relevant activities <a href="#send-all-relevant-activities" id="send-all-relevant-activities"></a>

Whenever a **user** performs an **action** on your **platform** that falls within the list of supported actions, you should send an **activity**. While in theory you may choose to send only some actions, failing to track all actions can lead to incomplete or inaccurate analytics.

### Include as much information as possible <a href="#include-as-much-information-as-possible" id="include-as-much-information-as-possible"></a>

The **metadata** of the activity object can contain valuable contextual information that enhances analytics.

For example:

* Adding a `metadata.orderId` property with the order ID allows you to [group purchased items](/product-discovery/tracking-and-sending-events/activities/purchase.md#properties) -into specific orders.
* Adding the `segments` property to the activity object allows for analytics based on different tags such **mobile** vs **desktop**, or **Chrome** vs **Safari**.
* [Adding information around the user](/product-discovery/tracking-and-sending-events/identities/working-with-identities.md#segments-and-traits-xo-specific) through the user.traits and user.segments properties allows for analytics based on user groups.

### Always include the source ID if available <a href="#always-include-the-source-id-if-available" id="always-include-the-source-id-if-available"></a>

The [activity object](/product-discovery/tracking-and-sending-events/activities/activity-object.md) contains the `sourceId` field. The field is not mandatory as it's not necessary for every type of action. However, this doesn't mean that you should omit it. You should always add the **source ID** to the activity object if it is available.

### **Store and keep sending the session ID** <a href="#store-and-keep-sending-the-session-id" id="store-and-keep-sending-the-session-id"></a>

As soon as a user lands on your platform, a **session** **ID** is generated for the user. This can be done automatically via the library, or by you. The next time the user connects, the [session ID](#store-and-keep-sending-the-session-id) allows us to identify them.

If you handle it yourself, you need to store the session ID in a cookie or equivalent storage.

If you use the library, the session ID will be stored in **local** **storage** on the user's browser.

### Send and update users identities on log in/log out <a href="#send-and-update-users-identities-on-log-in-log-out" id="send-and-update-users-identities-on-log-in-log-out"></a>

When the user logs in you should add their **logged** **in** ID that you have in your system (such as an **ecommerce** ID) to the information sent in the activity object. While you can also only keep using the **anonymous** **session ID**, we recommend that you also send over the **known logged in ID.** This allows for the user behavior tp be tracked across multiple devices.

When the user **logs ou**t, you should clear the **logged in ID** and no longer send it. You should also generate a new **session ID**. This is done automatically when using the SDK.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://crownpeak.gitbook.io/product-discovery/tracking-and-sending-events/best-practice.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.