I had the same business requirement and essentially determined the same thing you did, namely that metrics really isn't designed to do something as detailed as this. Now I haven't dug deeply into it, but the new Performance Analytics add-on might be able to address this need, and potentially be a far simpler solution: Module 1: What is the ServiceNow Performance Analytics Application? Unfortunately, there is an additional cost associated with this new fancy add-on, which might actually be worth it if it does everything it claims to do.
All that said, I needed to address the business requirement before this new Analytics engine was even available. It was a lot of work and quite tricky, but I managed to do so via the following steps.
1. Extend the target table of interest and name it something like for example (u_incident_snapshot)
2. Create a new reference field on this extended table to refer back to the task that triggered it. I.E. u_reference_task (reference to the incident table)
3. Create a new boolean type field, or any other type of field that you can use to track whether or not a new field change has occurred. For example: u_change_complete. Set to true when any of the targeted fields change again.
4. Create a business rule on the target table that watches for the field changes you are interested in capturing. For example, I only cared about capturing changes when either the Assignment Group, Assigned To, or State of a ticket changed. Configure this business rule to trigger the start of a custom workflow (recommended approach) that will iterate over all properties of the current record and insert their values into a new record on your extended snapshot table. Make sure to set the value of the reference field back to the original ticket. Also you would include code that first queries the snapshot table to look for any existing record that who's u_change_complete value is false and set that to true before inserting the new snapshot record into the table.
5. Finally, create an SLA Definition that will run against the snapshot table when a record is created and that will stop when the u_change_complete field value is set to true. If you want to implement a pause condition for the SLA you'll need to do that via creating a new field on the snapshot table that you can set to pause and unpause the SLA, this is necessary because SLA Pause conditions do not seem to work when dot walking to a field in a related record.
The end result of all of the above steps is that you will have a captured snapshot in time of all field values in a ticket for every instance when a targeted field changes, thus multiple snapshots. Each snapshot will have it's own SLA that you can examine and aggregate together with other snapshots which are similar. After you have all this in place the next challenging part becomes creating meaningful reports on all that raw data, aggregating it all together can be a painful exercise but well worth the results due to the level of detail you can glean about the life of a ticket.
Here is a screenshot of the type of details I was able to capture using this approach. This shows the life of a ticket. It's an expanding list view of custom tables that were built to show the aggregated results of the snapshot SLAs that ran during State, Assignment Group and Assigned To changes. Populating these tables required some scripting, aggregating and calculating against the raw data, but I think it demonstrates what you can do with data captured in this detail.
I hope this helped to give you some ideas, and that you find the solution you are looking for.
