> For the complete documentation index, see [llms.txt](https://fredhopper.gitbook.io/product-discovery/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://fredhopper.gitbook.io/product-discovery/tracking-and-sending-events/best-practice.md).

# Best Practice

Details to be aware of when using the Fredhopper front-end tracker for optimal usage.

### 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.