What’s the best way to hack the conversion value field from SKAdNetwork?

I agree with everything stated in the previous answer & I would tend to agree that it would be wise to be intentional about how you use the conversion value, but I would like to point out that if Apple observes any abuse of SKAdNetwork (e.g. "hacking the conversion value to potentially gain more knowledge about the user than they want you to have) you can fully expect them to shut it down. My suspicion is that they would consider it a security vulnerability the same way they view attempts to circumvent ITP. There was a short time that people thought they were geniuses because they were moving from cookies to local/sessionStorage for tracking purposes, etc. and that was ultimately short-lived & turned out to be pretty much a waste. YMMV, but I would encourage finding ways to operate within the bounds that Apple sets & avoid chasing "hacks".

I don't know that there's any way to "hack" it, per se, but it's certainly possible to use the Conversion Value field wisely.

First, a primer:

• The Conversion Value parameter in the SKAdNetwork postback is a 6-bit value, meaning it takes the form of six 1 or 0 bits (eg. 010101). Only 64 values are possible with a six-bit value (2^6);
• The Conversion Value is updated using the native iOS updateConversionValue(_:) method;
• The Conversion Value is set via a convoluted timer logic (described in detail here), but at a high level: the highest Conversion Value updated by the app for the user within a rolling 24-hour timer is sent via the SKAdNetwork postback. Only one postback is sent via SKAdNetwork, meaning only one Conversion Value is ever captured for an attributed user.

What's the best way to utilize the Conversion Value parameter so as to optimize campaign performance?

First, it's important to recognize the tradeoff between value captured in the Conversion Value ("value" here referring to monetization history / potential of a given user) and lapsed time between install and postback. The sooner an ad network receives a signal that a given user is a (potential) monetizer, the sooner it can validate its traffic targeting to reach more users like that. So the advertiser should strive to have the Conversion Value sent via the postback as soon as possible after the user's monetization potential has been sufficiently vetted.

But obviously it takes time to vet a user's monetization potential, and the Conversion Value can only be sent once. I think a sophisticated Conversion Value strategy involves associating real-time LTV estimates for users with various cumulative events that they have completed in the app, and encoding those LTV estimates through the Conversion Value. Obviously these estimates would have to be grouped into tiers, since the Conversion Value can only take 64 values, but that still provides a great degree of freedom and specificity in defining groups (eg. 000001 is users expected to spend $0.01 - $1.99, etc., 000011 is users expected to spend $2.00 - $4.99, etc.).