What is the primary key of action (schema vs API)?

Hi all, I am trying to understand the relationship in Matomo data from looking at the schema to the API responses.

I understand the uniqueness of a Visit, however when looking at the database schema for Actions and Events, it is a little less clear.
In the schema (https://developer.matomo.org/guides/database-schema), I see that the key on log_link_visit_action is id_link_va, but this does not come back in the API response.

I can also see that there is a unique constraint on log_link_visit_action for visit and time, indicating that this table is page visits, but I can also see that a user of our site hits one page and we trigger three events, we see one action and three event records, which is correct, but they have the same idpageview, but different actiondatetime values.

The context of the question is we periodically call the API, store the results and then upsert on the next call. The logic we currently have is convoluted and I’d like to streamline it, but without knowing the relationship from the database schema to the API response, I am missing details to make this happen.

Basically, I’d love to know what exactly do idpageview, pageid, pageidaction and pageview position from the API (i.e. Live.getLastVisitDetails) actually relate to in the schema (if anything). There is a query here that details the underlying joins from the raw database. https://matomo.org/faq/how-to/faq_24536/#2-direct-read-only-access-to-the-mysql-database-not-available-for-matomo-cloud

My thoughts here are that, within a unique visit:

  • idpageview - the unique identifier for the pages visited
  • pageviewposition - the pages the user has clicked on, if they visit five pages, this will have multiple records for the values 1-5, effectively just a partitioned visit order by idpageview (?)
  • pageidaction - I don’t quite follow this one, it seems like if you log an action, it gets a new ID and all events inside the same idpageview get the same ID here (which kinda makes sense as they aren’t actions, but they aren’t null and our type = search records have 0)
  • pageid - this is the one that in the API response seems unique, and I think might somehow be able to be considered a PK, but I cannot find any information on this

Basically, I think I am at the end of trying to find the answer in the documentation … I think I am just seeking clarification as to what pageid exactly relates to or how it is constructed as well as confirmation that my thoughts above are correct. I have suspicions, but I’d like clarification that this is the case rather than me making an assumption.

If I have missed this in the documentation, I am happy to receive any directions as to where this is.

Thanks in advance!!

1 Like

Hi @Gannon

See https://demo.matomo.cloud/?module=API&method=Live.getLastVisitsDetails&idSite=1&period=day&date=yesterday&format=xml&token_auth=anonymous


I think the pageId is the id_link_va.

The idpageview is the page where the event occured… It should be unique… during one single visit (this value is set by the client)!

Thanks Philippe - I think you are correct, I am just hoping to get a categorical confirmation that this is the same thing before we rebuild some of our jobs around this logic. Appreciate your input, Matomo told me the Core Team are going to review and give an answer. Cheers!!

1 Like

Hi Gannon, did you get any further response on this, as I’m trying to do something very similar. Many thanks.

Hey Millstone1998 - I followed up to get a categorical answer and they advised they are having someone look at this again. If the naming was consistent or there was a database schema to API response map that would be ideal.

I think what would be ideal here, is just the query that is used to populate Live.getLastVisitsDetails (https://developer.matomo.org/api-reference/reporting-api#Live) so that we can migrate from API reporting to Data Warehouse.

Hi Gannon, first of all apologies for taking so long to get back to you.

To confirm your understanding within the context of a single visit, here’s a breakdown of the key fields:

idpageview - This is a unique identifier generated by the tracker for each pageview. It helps group actions (like events) that happen during the same pageview.

pageview_position - This indicates the order of the pageview within a visit. It starts at 1 for the first page viewed and increments with each new pageview during the same visit.

pageidaction - This is the ID that references the page URL or title in the log_action table. It represents what page was viewed (e.g., /about-us), and is shared across visits that see the same page.

pageid- This is the primary key of the action recorded in log_link_visit_action, corresponding to the field idlink_va. It uniquely identifies that specific action (like a pageview or event) in the database.

Let me know if this helps, and if you have more questions then fire away and i’ll make sure to respond quickly.

1 Like

Thanks Matthew, this is super helpful!
The one thing that is missing is how goals (and any other actions) relate if they are handled differently.
Based on your explanation above, I can see within our site that idVisit 34600304 has two actionDetails for idpageview SC2rei, so these occured on the same “action” (page view). One is an action, so this makes sense, but then one is a goal.
The action has a pageID, but the goal does not. It has a goalPageId with the same value. So, these are therefore obviously related (by both idpageview AND pageID via goalPageID), but now I don’t have anything unique to identify a goal.
I can see in the schema that goal is unique by idsite and idgoal, so this refers to the reference entity, but what about the goal that is reported in actionDetails?
log_conversion looks like it might be the one, so then the key is idsite, idvisit and buster … so now my question is what buster is. The logical assumption would be that this is the pageID, but then that would assume that you can only trigger one goal per goal type per action (being action, event, download, search, etc.).
Are there any other types that we need to be aware of here that have special conditions - action, event, download, goal, outlink, search - is this the comprehensive list? I cannot find one on your website, just this which lists “such as” - https://matomo.org/faq/general/what-is-the-difference-between-page-event-action-and-download-url/
Thanks in advance … I think I am nearly there with the end of my questions!!

Thanks Gannon - glad to hear the previous response helped!

You’re asking excellent questions, and you’re absolutely right that goals can behave differently compared to other action types.

Understanding Goals in the Context of Live.getLastVisitDetails

Goals and pageID / goalPageId:

  • In Live.getLastVisitDetails, goals typically do not have a pageID (which corresponds to idlink_va from log_link_visit_action) because they are stored separately in log_conversion, not log_link_visit_action. However, goalPageId is often included and references the action (idlink_va) that was active when the goal was triggered - so this can be used to relate the goal back to the context (i.e., the pageview) in which it happened.

  • buster in log_conversion:
    Yes - buster is the field Matomo uses to ensure uniqueness of conversions (in combination with idvisit, idsite, and idgoal). It’s not the same as pageID. Instead, it’s typically:

  • A random number generated at time of conversion, OR

  • Derived from serverTime or another entropy source
    … depending on the goal type and whether it’s triggered by JS, manually, or via import.

So your assumption that buster is pageID isn’t quite accurate - but the presence of goalPageId gives you the relational hook you’re probably after.

“Are there any other types that we need to be aware of here that have special conditions - action, event, download, goal, outlink, search… is this the comprehensive list?”

Primary Action Types in log_link_visit_action

API type Description Special Notes
action Pageview Standard
download Click on a download link Standard
outlink Click on an external link Standard
event Custom events Standard
search Internal site search Special: has idaction_name and idaction_url referring to search terms
goal Tracked in log_conversion, not log_link_visit_action Requires special handling

Other Special Cases

  • Content Interactions
    Tracked as events but may include fields like interactionPosition, contentName, etc.

  • Ecommerce
    Uses separate tables like log_conversion_item and introduces more complexity (cart updates, orders, revenue).

  • Custom Dimensions
    Not action “types” themselves, but stored alongside actions and conversions in separate tables.

Does this help ?