### Search Result Page View Tracking
Go to your Search Result Page Template and add the search specific tracking parameters in the Global Tracking snippet. If your search result pages are loaded via Dynamic Refresh, please add additional handlers to be able to [track virtual page view interactions](🔗).
#### Faceting, Filtering and Pagination on Search Result Pages
If a user applies a facet filter and refreshes results, Bloomreach expects that the Search Result Page View pixel fires each time a filter is applied. Bloomreach uses this information to understand which filters are commonly used. In case your implementation is such that pages don't reload when a user applies a filter or facet, please add additional handlers to each filter/ facet to be able to [track virtual page view interactions](🔗). If your category pages are paginated, Bloomreach expects that the Search Result Page View pixel fires each time a user navigates to the next or previous Search Result page. If your Search Result pages don't reload when a user navigates to the next or previous page, please add additional handlers to the 'next' and 'previous' links to be able to [track virtual page view interactions](🔗).
## Search Result Page View Variables
|Variable||Value type, example||Description|
|br_data.search_term||string, "blue dress"||The value of the search query describing the page.|
## Native App Implementation
For details on using the Discovery [Android](🔗) and [iOS](🔗) SDKs for specific Native App Implementation, refer to their respective linked guides.
You can include the [Global Page View variables](🔗) and the following variables.
ptype = search
search_term (see above)
# What to do for keyword searches with no results
If a user entered search term results in no results being sent back by Bloomreach - you will still need to fire a Search Result Page View pixel on the resulting page and pass the search term entered by the user.
From the combination of the Search Result Page View pixel and the API call received, we will track that this query results in no products being returned and use this data to populate the [null results report](🔗) in the dashboard.
We have seen a trend for some clients to report the no-results pages simply as "_other_" or redirect the users to a generic "_not found page_" type.
You are free to redirect users to any page of your choosing when no results are returned - however, if you wish this to be tracked, the Search Result Page View pixel must fire on the resulting page with the necessary details.