category_page_view

Used when a user views a category page for a specific “family” or “group” or products or content. This is a strong indicator of what types category of products or content the user is interested in.

A pseudo-unique substitute for the User Id. We use anonymous_id to identify a visitor who has not signed in. anonymous_id can be implemented using mechanisms such as cookies or browser localStorage. If anonymous_id is not given, we will default it to SHA1(<API key>:<IP address>:<user agent>:<date>). When a visitor signs in and the user_id and anonymous_id are both present, the anonymous_id will be linked to the user_id along with the past interactions associated with it.

Categories usually fall in a hierarchy, such as Home & Garden > Kitchen & Dining > Kitchen Tools & Utensils > Sushi Mats Use this field to specify the full hierarchical list describing the category the user is viewing.

The levels should be listed from broad to narrow: ["TOP_LEVEL_CATEGORY", "SUBCATEGORY_1", "SUBCATEGORY_2", ...]. This field is only used by the category_page_view interaction type, but this data is very useful for determining the user’s interests. Example:

[
 "Home & Garden",            // TOP_LEVEL_CATEGORY
 "Kitchen & Dining",         // SUBCATEGORY_1
 "Kitchen Tools & Utensils", // SUBCATEGORY_2
 "Sushi Mats"                // SUBCATEGORY_3
]

Dictionary of extra information that provides useful context about an interaction. We use context information to make recommendations tailored not only for each user, but also for their current browsing context. For example, a user browsing on a desktop may have different browsing behavior than a user browsing on mobile phone. As another example, a user who gets to the site via a certain campaign you run on Facebook may have very different interests than a user who visits your site directly.

Context information is also useful for personalization for entirely new visitors, as we can immediately personalize their experiences based on their context alone (e.g. the referrer or the campaign they clicked through).

Example:

{"context": {
    "campaign":
    {
        "name": "spring_sale",
        "source": "Google",
        "medium": "cpc",
        "term": "running+shoes",
        "content": "textlink"
    },
    "truncated_ip": "1.1.1.0",
    "locale": "en-US",
    "region": "US East",
    "page":
        {
            "url": "https://example.com/miso-tshirt-123ABC",
            "referrer": "https://example.com/",
            "title": "My Product Page"
        },
        "user_agent": "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0)"
    },
    "custom_context": {
        "other_context_var_1": "value_1",
        "other_context_var_2": "value_2"
    }
}

How long (in seconds) the user stayed on this page, or consumed (listened, read, or watched) a product. This field is optional, but it's very important in scenarios where consumption duration matters, including product_detail_page_view, category_page_view, watch, listen, and read. For example, if a user only views or consumes a product for less than 5 seconds, that user is probably not interested in the product. On the other hand, if a user stays on a page for a while, it usually means they are seriously engaging with or considering the product. When duration is absent, we will use the timestamp of the next interaction to infer a rough duration value.

Example:

{"duration": 61.5}

Miso-generated unique Id for each recommendation or search result. Maintaining this Id for subsequent page views is important to Miso's performance, as we use miso_id to track and fine-tune the performance of personalization and search results. When a user clicks on a recommendation or search result, you should pass the associated miso_id to the next page view, and associate the miso_id with the interactions that take place on the page (e.g. product_detail_page_view, add_to_cart, add_to_collection, like, etc.). In this way, Miso will learn which recommendations work and which didn't.

Example:

{"misoId": "123e4567-e89b-12d3-a456-426614174000"}

The ISO-8601 timestamp specifying when the interaction occurred. If the interaction just happened, leave it out and we will default to the server's time. If you're importing data from the past, make sure you provide a timestamp. It is recommended to include milliseconds in the timestamp to provide a higher time resolution.

Example:

{"timestamp": "2018-11-07T00:25:00.073876Z"}

Identifies the signed-in user who performed the interaction. We will use user_id to link Interaction records to your User records. Therefore, it is important to keep this consistent between the two datasets.For visitors who have not signed in, see anonymous_id.