Capture signals
Signals flow into Fusion from either a configured datasource or through the frontend application via the Signals API. Before you begin capturing signals, you should determine what kinds of signals and attributes to capture as well as how long to store signal data.
Before you begin
There are some criteria to consider before capturing signals:
-
How many daily search requests does your website receive? This will help estimate how many click signals you can expect to receive.
-
What kind of data collection do you perform on users? If you don’t track
user_idconsistently you may encounter problems with users-for-item recommendations. -
How many datasources do you use? This will affect how you apply boosting and what fields are relevant.
-
Are you proficient in Javascript? If you’re sending signals from your frontend application or website, you’ll need to use Javascript in your implementation.
Decide what to capture
Signals can include as much or as little data that you wish to track. Depending on your industry and use case, you may decide to track certain signal types and attributes over others. The following table lists some of the most common types of attributes used in developing a strong search experience:
Essential |
Original query term or browser context |
Event type |
|
Product or doc clicked |
|
Search context type |
|
Query filters |
|
Query sort |
|
Recall size |
|
Page number |
|
Click position |
|
Session ID |
|
User ID |
|
Customer ID |
|
Event timestamp |
|
Search response time |
|
Platform |
Type |
Name |
|
OS type |
|
OS version |
|
Browser name |
|
Browser version |
|
App version |
|
Profile info |
Gender |
Age range |
|
Tenure |
|
Experiment |
Experiment ID |
Variant ID |
|
Variant name |
|
Other |
Breadcrumb |
Referrer |
|
Product ID |
|
Family ID |
|
SKU ID |
|
Source |
|
Login status |
|
Store ID |
|
Location - Region |
|
Location - City |
|
Location - State |
|
Location - Country |
Send signals
When sending signals to Fusion, signals should come from a protected backend server and not directly from the browser. Additionally, the server should perform a store-and-forward batches pattern rather than individual signal payloads to avoid timeout errors.
Create a retention policy
Signals use up a significant amount of data storage in your Fusion instance. Typically, you should store 3-6 months of raw signals in Fusion before archiving them into a longterm storage solution. Signals are not automatically deleted by default, so you should set up a REST job to regularly delete old, unused data.