Potential future features

Beyond this initial release of the Metro 2 tool there are additional future enhancements that could be explored further:

• Importing and parsing data
• Running and storing large data sets
• Analyzing an evaluator’s results
• Reference materials and other resources
• Administrative features

Importing and parsing data

• Make parsing faster: Improve the speed by which application parses new data.
• Additional ideas: The additional ideas are for reference, they typically involve significant work, are more speculative or have not been prioritized.
  • Create a solution that lets users parse data without a developer’s help.

Running and storing large data sets

• Resolve issues with high data volume: Very large Metro2 datasets cause problems with database queries taking too long or failing to resolve at all. These issues are compounded when the Metro2 database stores multiple large events at once.
• Retain sample of event data after use: Until the above issues is resolved, we have decided to only keep one set of data in Metro2 Production at a time. When we delete an older event’s data, we could retain a sample of data (i.e., representative sample data for all evaluator hits) for that event. This way, users could have an idea about the results and see the fact patterns, even if they’d have to reload the data to have full access.
• Additional ideas:
  • Run multiple events/ongoing access: Stakeholders wanted tool to be able to run multiple events. At the very least, they’d like to be able to have access to data even if tool was running a different event.
  • Archive events: Determine how to handle events that are no longer active.

Analyzing an evaluator’s results

• Add context about the total number of records reviewed: Adding this number would allow users to have more context for the number of inconsistencies that were found. (E.g., The significance of an evaluator with 10,000 hits out of 100,000 records may be different than one that had 10,000 hits from a total of 10,000,000 records.) Recommend that we add this total to the event overview listing all evaluators with hits and each evaluator results page. Additional context, like the total number of accounts or portfolio type, might also be useful.
• Finalize sorting functionality: Currently sorting only affects the results that are visible on the page. Enhancements would ensure that all results were sorted, not just the ones visible at the time of sorting.
• Add date ranges to filters: This would help users focus on results from a particular period.
• De-duplication: "There are 4 problems, but those problems show up in up to 8 evaluators. It would help to know which are duplicative" This has already been partially solved by evaluator consolidation, but team has discussed doing something like 'adding check boxes' to the event overview screen to tally certain evaluators and show the total accounts affected.
• Additional ideas:
  • Eliminate filter values that have no results/ relevance for an evaluator: This would make it easier for users to have meaningful results from using the filters. We’d also like to explore the level of effort required to add counts to filters.
  • Show a "unique accounts affected" tally adjacent to the evaluator results table that would update when filters are applied. It might be helpful to have a way to view results on the evaluator page by unique accounts, and possibly see how many times, or in which months, an evaluator has hit on a particular account. (This is related to duration/frequency bullet below.)
  • Show duration/frequency: Explore how to show the duration of inconsistency to be able to answer questions like: when did it start? when was the most recent hit? did it affect many accounts for 1 month or fewer accounts for many months?
  • Standardize the column order of the table: Currently each evaluator table shows the columns used by the evaluator and the columns used by the filters. We’d like to explore showing all columns and then users could hide ones they don’t want to see.
  • Download all columns: Related, during testing users wanted options when downloading information: Smaller set of data (the representative sample results included in the table); All results (with only the columns relevant to the evaluator); All results (with every single column). Currently, when looking at an evaluator’s results, users are unable to download every field associated with every tradeline. Instead, only a curated set of fields is included with each evaluator.
  • Download all account data for multiple accounts: There was also the desire to download all account data in bulk, rather than individually going to a specific account’s page and downloading its data. Instead, users wanted to download all data for up to 50 accounts at a time.
  • Add medium-priority evaluators: If necessary, we could add more evaluators that might be helpful to identify consumer harm.
  • Query database: Users can run SQL queries on the event data to identify patterns that aren't easy to see in the interface, without worrying that they’ll modify the data.
  • Create simple, maintainable charts: To more quickly show trends, we think that charts could help visualize the concentration of hits, offer the ability to zoom into a specific issue, or highlight how long a problem has persisted.
  • Ability to bookmark an account: Custom URL change makes it possible to get back to particular result(s) by copying and saving the URL, but there’s no easy to bookmark an account within the interface.
  • Add tooltips to the column headings: The table provides the Metro2 codes along with a brief description, however understanding exactly what terms like “Date of account information” actually represent is a different matter. Early prototypes included tool tips next to column headers to offer a brief explanation of what these items represent. This may be especially helpful for new users or those who only occasionally use Metro2 data in their work. However, there may be other solutions that are less effort or provide more space to explain what these terms mean and how to interpret them.

Reference materials and other resources

• List of all evaluators: Admin users can see all evaluators in the admin interface, but that ability isn’t available for regular users. Regular users can only see the evaluators that triggered for an event. This feature would allow regular users to see all the evaluators within the interface, including ones that did not produce results.
• Additional ideas:
  • Cross-referencing with direct disputes: Given a list of account numbers had disputes, show which of those accounts had evaluator hits in Metro2. When showing lists of evaluator results, consider if there’s a way to indicate which accounts have corresponding dispute data.
  • Cross-referencing with complaints: Use Complaint Explorer API for added context. Given a list of account numbers that had complaints, show which of those accounts had evaluator hits in Metro2. And, when showing lists of evaluator results, consider if there’s a way to indicate which accounts have corresponding complaints.
  • Include the Credit Resource Reporting Guide (CRRG) in HTML: As a PDF the CRRG is difficult to navigate. Converting it to HTML will allow users to link to specific sections of the CRRG in an evaluator’s metadata. However, it is updated every year, and we have not explored the level of effort/maintenance this would be to keep this up to date.
  • Adding event-specific content: When administrators edit evaluator metadata, the update is currently system-wide and will show for all events. However, there’s a desire to allow content to only appear on a single event. This could either be marking (highlighting or flagging in some way) a particular row for an event in the interface, or to add comments. A highlight or comment would show for all users and any subsequent visit to the page, but it would be event-specific and would not show up in a different event. This feature could apply to evaluators, accounts, or months of a particular account. (feature prioritization email)

Administrative features

• Make the admin site more user-friendly: Customize the admin interface to make it more clear, simple, and easier to use.
• User guide editing: Rather than having static user guide pages, Admins can easily modify the contents of the user guide pages.
• Additional ideas:
  • Improve styling of content: This includes the ability to bold, add bullets to evaluator descriptions. Adding this would allow us to remove the long description formatting workaround we added in the front end of the tool.