Which table and column does trackPageView custom context display in?

So far the table I expect the data to exist in, is empty. The schema name is like, trackpageview_context, and the table TRACKPAGEVIEW_CONTEXT_1 is empty. The data being passed is an object. I read the data for a context should be flat. Is this an issue?

data: { myObj: { "myProp": "a string", "myOtherProp": ["some value in array",1], "myLastProp": {"etcObj":true} }, },

What is the method call you are currently using to track? And what database are you using?

If it’s trackPageview this should appear in the atomic.events table (as event = 'page_view'). It sounds like you may be trying to use a a custom context however.

Hi @sandraqu

I think theres a couple of things to check here. However, if the data isn’t landing in the expected table it’s likely failing validation as part of the pipeline validation process for your schema, or never being sent by the tracker.

  1. You should have created a JSON Schema for this custom context and uploaded it to an Iglu Server/Repository which is attached to your pipeline.
  2. The data in your context validates against the JSON Schema you’ve created for TRACKPAGEVIEW_CONTEXT_1.
  3. This is the same as @mike’s questoin above, you’re sending a page view context, is this additional data on top of a trackPageView event? Could you share your snippet of code where you are tracking this event?
  4. Do you see the event being sent out of the browser, if you look in the network tab, or using the Poplin Snowplow extension?
  5. Probably not the issue, but worth mentioning. This is an interesting array "myOtherProp": ["some value in array",1] as it is mixed types, you might be better with a single type within an array from an analysis in the warehouse point of view.

Thank you both for your replies. I am using a custom context in an trackPageView event.
We are using Snowflake for database. Data is visible on the browser via Poplin plugin. Data is valid. Table TRACKPAGEVIEW_CONTEXT_1 is empty

    function snowplowTrackPageView() {
    window.snowplow('trackPageView', null, [
            schema: 'iglu:com.domain.subdomain/trackpageview_context/jsonschema/1-0-1',
            data: {
                "myObj": objData,

ps, myObj is just bogus data. I was feeling lazy and wrote a 1 in the array.

Should I be looking for myObj data in PAGE_VIEW_EVENT table instead?
Which column?

If you take your JSON Schema for iglu:com.domain.subdomain/trackpageview_context/jsonschema/1-0-1 and the value of data in the above sample, does it validate as expected in: https://www.jsonschemavalidator.net/?

My spidey senses are thinking this is failing validation in the Snowplow pipeline which is why it isn’t ending up in the warehouse. You might have to inspect your failed events in your pipeline to find the error for why this is failing, or spin up snowplow-micro and point it to your Iglu Servers or use snowplow-mini and add your schema to that, then inspect the bad index in Kibana.

Thank you, Paul. The schema and data value validate. The data is being used in self describing events without issue. If the custom context data is supposed to be showing in TRACKPAGEVIEW_CONTEXT_1, then there is an issue somewhere, but none that we can see. I will use the tools you have recommended.

I have learned that our enrichment process is not routing custom context to the TRACKPAGEVIEW_CONTEXT_1 table.

@sandraqu That’s right. With Snowflake you do not get data loaded in one main events table and child-tables per custom event or context. Instead, you should find the trackpageview context in CONTEXTS_COM_DOMAIN_SUBDOMAIN_TRACKPAGEVIEW_CONTEXT_1 column of your events table.

The child tables are only really necessary for loading into targets like Redshift where the SQL dialect doesn’t have great support for nested data.

I understand now. Thank you all for helping me understand custom context and its destination table and column.