How was your timing on this Data Insights section? Were you able to finish the section and take at least a decent stab at each problem, or did you run out of time and have to throw some random guesses?
If the latter, it'd be well worth your time to revisit your already-familiar official D.I. materials, but this time with an emphasis on
efficiency.
Which bits of the original information set are actually worth reading/examining in detail at the outset? Which parts are worth briefly scanning—to ascertain what type of information is in those parts and how that information is organized, but not actually to pore over the datapoints themselves? Which information, if any, is best skipped entirely unless/until you actually get a question that asks about it?
.
As you consider these aspects of your approach, please keep in mind that
giving you TOO MUCH INFORMATION is THE uniquely defining characteristic of Data Insights—essentially the only common thread that runs through the otherwise wildly diverse range of problems in DI.
The contrast here with the older parts of the test rlly can't be overestimated. Quant problems, in particular, pretty much always hand you
exactly what you need to solve them—no more, no less. Hence the viability of strategies like backsolving, which depends utterly on this neat packaging of everything that's needed and nothing that isn't. ("Start from an answer choice and work back through the given statements
until you've used all of them; if everything agrees / there are no contradictions at that point, you've got the correct answer" —> If Quant problems ever contained superfluous information, the boldface part of this protocol would no longer work.)
If you don't have a strong intuition for DI problems as "TOO MUCH INFO" from the outset, then drawing direct contrasts with this quality of Quant problems should help you shore up that intuition—which, in turn, will make you more picky ("picky" is a good thing here!) about which information you actually bother to scan at the start of a DI problem group.
.
If efficiency isn't really an issue for you on DI, then I'd recommend deep-diving into any error logs you might have kept as you did DI practice problems, looking for
concrete patterns in the errors and/or oversights that caused you to get problems wrong.
When you identify such a pattern, don't stop there (in other words, don't just "log the errors"). Equally important, try to identify CLUES or SIGNS that will tip you off to pay more attention to this-or-that specific aspect of the problem going forward.