What is the best way to implement SKAdNetwork? What are the pros and cons of each?

There is no concept of a 'network-specific SKAdNetwork implementation'. If you're using a third-party SDK to enable SKAdNetwork (MMP SDK, Firebase, Facebook SDK, etc.), all of them are simply wrapping the same two native iOS methods: registerAppForAdNetworkAttribution() and updateConversionValue(_:). You can also add your own code to call these two methods, and the effect will be exactly the same.

The only implementation-specific part of SKAdNetwork is when the updateConversionValue(_:) calls are triggered. You'll want to ensure that only a single party is managing this process, because it's very easily to get messy data.

If you're choosing between various SKAdNetwork implementation options, here are some details to keep in mind:

• MMP SDK. This is our recommended option for most apps. SKAdNetwork is "shared infrastructure" for all your ad network partners, just like your MMP. Using your MMP's SDK to manage SKAdNetwork is the simplest technical option (you don't need to make any in-app code changes, aside from updating to the latest SDK version), and you'll also benefit from a number of other conveniences, including easy dashboard-based mapping of SKAN conversion value calls, and automatic conversion value "decoding" for networks that support it (meaning, the network can call an MMP-provided API endpoint to understand which event correlates to a particular conversion value).
• Network-specific SDK (Facebook, Firebase, etc.). If you're not already working with an MMP and your acquisition campaigns are strongly weighted to a specific large network, this may be a good option. The network's SDK may provide automatic conversion value management, which could help that specific network better optimize campaigns (though networks can get the same functionality by integrating with your MMP's conversion value mapping API). However, the downside of this option is that your conversion value schema won't be meaningful to any other network.
• Custom code implementation. This is the most flexible option, but also the most difficult because you'll need to handle all of the conversion value mapping yourself. However, if you're planning to skip simple event mappings for your conversion value strategy and instead build a sophisticated, predictive LTV model, this is the best approach. This is also likely to be your best option if you use an MMP but rely heavily on server-to-server events, because updateConversionValue(_:) calls must happen locally from each individual device and most MMPs are not equipped to forward those server-side events down to the local client.

Regardless of which option you pick, it's important to keep in mind that the implementation will be shared by all networks you use.