To figure out: do we log how a record is created or imported?

[mietcls]

Question

To figure out: do we log how a record is created or imported?

Do we know how records are created: manually, through WoS import, DOI import, ...?
Do we know which records have been created together (e.g. multiple records were imported at the same time through one WoS import)?

What we need to know:

• How is a record created
• By whom
• And at what time

-> So we will know what import ways are most important and we should give priority
-> So we will know how many records a person creates within a certain time span, which will give us insights for the import flow.

Context

1. This gives us more freedom in communicating about what happens in Biblio
2. This gives us insights in which ways people import, and we could improve or educate.

[nicolasfranck]

A sort of audit log, i.e. a list of event object, containing attributes like user_id and action? Hard to fix this backwardly

[netsensei]

Turning this into a discussion.

There are two options to accomplish this:

• Write the information in the record (dataset, publication) itself.
• Write the infromation into biblio backoffice's log files.

Pro's & cons

Option 1:

• positive: We already store creation date & creator in the first snapshot.
• positive: We can very easily query that data through the API client we've build
• negative: We need to introduce a new field that stores the creation manner. Is this info valuable enough to persist in the record forever?

Option 2:

• positive: we don't tack new fields to a record for tracking / analytics purposes.
• negative: we need to process the log files to find that information, which means extra code.
• negative: we only store log files for 30 days.

Discussion:

Option 2 is great if we want to track this type of information temporarily (e.g. for the next 30 days, for a single analytics probe of how people create records). Option 1 is preferred if we want to persist that information with the record permanently so it can be analyzed e.g. 5 or 10 years down the line.

So, question: Will tracking how records are created be a one-off thing? Or do we want to cling on to this data into the far future?

@nicolasfranck This question pertains to how people are adding records right now. So, unless there's a need to expand the query to include how records where added the past, we don't need to concern ourselves here. You're right though: retro-actively we can't reconstruct how our oldest records were added (these go back to 20 years).

(@mietcls @nics)

[mietcls]

Has anyone already checked what is tracked already? Can we start from there?

[netsensei]

We're already tracking per record:

• The user who created the record
• The datetime when the record was created

These are stored as fields in the record itself. Notably, the datetime and the user who created the first snapshot of the record are relevant.

What we don't capture: the origins of the record (e.g. WoS, CrossRef, Bibtex, Manual.

[mietcls]

Tracking trends:

• We will need to track the origins of the record so we can make more metrics based decisions. Right now we're in the dark and navigating on hear-say.
• One-month metrics are not interesting if you want to start seeing trends and anticipate where you want to go.

Added benefit:

• If we have information about where people got the information, we can also start thinking about automatically updating information from the sources that people use. There's probably multiple ways to update information, but this says something about what people actually use (and keep alive?). It would be nice to have a discussion about this with the team about the possibilities.

I do think we need to be mindful of the information we track, if you're talking about value:
1 Respect people's privacy (no sensitive information or dangerous combos)
2 Support researchers in their career (use what they put out there to support their voice and avoid double/bothersome administration)

How and where to store it: I trust your expertise, interested if there's an other way to keep this information.