Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding Oath (Verizon Ads SDK) adapter v1.0.1.0 #120

Open
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
2 participants
@mmullin
Copy link

commented Feb 26, 2019

This pull request adds the new Inline and Interstitial adapters for the Verizon Ads SDK. We plan to add support for Native and Rewarded Video mediation to the Verizon Ads SDK in a future adapter update.

@ericleich

This comment has been minimized.

Copy link
Member

commented May 3, 2019

Hey Mike, what timeline do you have for "future update"? Is your goal to release a first version of the dapter to publishers with just banner/interstitial support, or did you want to do rewarded/native for the first release?

@ericleich

This comment has been minimized.

Copy link
Member

commented May 8, 2019

Also, I'd like to get people off of Nexage/Millennial if they want to onboard onto Verizon (that is, don't have the MillennialAdapter and NexageAdapter classes in this CL. We don't want to be in a world long term where publishers have "Millennial Media" configured in the UI but it calls an Oath SDK. One big downside of this approach is those publishers won't get ANO for one thing. Also, the parameters configured in the UI for Millennial and Nexage have different keys that are annoying to maintain in the adapter, and may require retagging anyways if you no longer support the old versions of those credentials.

Publishers will have to take action to pull in the new verizon SDK and adapter, so it's reasonable to ask them to migrate their ad configuration too.

int screenWidth = context.getResources().getDisplayMetrics().widthPixels;
int screenHeight = context.getResources().getDisplayMetrics().heightPixels;

if (adSize.isAutoHeight() && adSize.isFullWidth()) {

This comment has been minimized.

Copy link
@ericleich

ericleich May 8, 2019

Member

Note: We are planning another feature that may result in publishers sending different sizes that are similar to standard formats (e.g. 328x52 instead of 320x50). We would expect mediated networks to fill a 320x50 in that case.

Question: Does your SDK need explicitly sized formats like 320x50 to be requested, or would your SDK naturally handle a 328x52 and return a 320x50?

@mmullin
Copy link
Author

left a comment

Hi @ericleich, sorry for the delay in getting back to you. Answers below:

Hey Mike, what timeline do you have for "future update"? Is your goal to release a first version of the dapter to publishers with just banner/interstitial support, or did you want to do rewarded/native for the first release?

Yes, the idea was to get an adapter with only banner and interstitial support tested and released for Verizon Ads SDK v1.0 release, with rewarded and native support to follow shortly after. It's been some time since this PR was submitted, and we actually just released v1.1 of the SDK last week. We'll likely have rewarded and native ready to submit this week.

Also, I'd like to get people off of Nexage/Millennial if they want to onboard onto Verizon (that is, don't have the MillennialAdapter and NexageAdapter classes in this CL. We don't want to be in a world long term where publishers have "Millennial Media" configured in the UI but it calls an Oath SDK. One big downside of this approach is those publishers won't get ANO for one thing. Also, the parameters configured in the UI for Millennial and Nexage have different keys that are annoying to maintain in the adapter, and may require retagging anyways if you no longer support the old versions of those credentials.

Publishers will have to take action to pull in the new verizon SDK and adapter, so it's reasonable to ask them to migrate their ad configuration too.

The downside to that approach is we're creating some easily avoidable publisher pain. Rather than a hard cut-over, another option is to deprecate the Millennial/Nexage support in the adapter, but leave it in for now to allow for a gradual migration. Then in a future adapter release, we can remove the Millennial/Nexage classes, giving publishers time to move their mediation setups over but also putting an end date on those configurations (both on the server and the client).

Question: Does your SDK need explicitly sized formats like 320x50 to be requested, or would your SDK naturally handle a 328x52 and return a 320x50?

Any ad size can be set on the SDK and sent on a request. If the expectation is that the AdMob SDK would request an irregular ad size that can be filled by a standard size, wouldn't that be something we could handle in the adapter itself? i.e. map non-standard sizes to standard ones?

@ericleich

This comment has been minimized.

Copy link
Member

commented May 22, 2019

Hey @mmullin ,

The downside to that approach is we're creating some easily avoidable publisher pain. Rather than a hard cut-over, another option is to deprecate the Millennial/Nexage support in the adapter, but leave it in for now to allow for a gradual migration. Then in a future adapter release, we can remove the Millennial/Nexage classes, giving publishers time to move their mediation setups over but also putting an end date on those configurations (both on the server and the client).

On Millennial/Nexage deprecation, we will have to phase out support at some point, and the release of a new adapter seems like the right time to do it. There will be some workflow challenges if we don't do this now. For example, if publishers grab the Oath adapter but also have the old millennial/nexage adapter in their app, they'll get duplicate class errors because both adapters have the same class name. Additionally, our team won't test millennial/nexage setups against the adapter, and there are risks we accidentally break something down the line later. Also, if publishers are going to do the work to move to a new adapter in their app, we'd want them to update their tagging to take advantage of ad network optimization features. If we put them on the Oath adapter without migrating them, they may never retag and we'll be stuck supporting this forever.

We plan to host the Oath adapter in maven/CocoaPods and write an end-to-end guide for the Oath adapter, and I think it'd be cleaner to ask publishers to follow that guide to migrate their tagging at the same time they migrate their adapter/SDK in-app. How strongly do you feel about keeping in Millennial/Nexage references? Do you still have publishers using a Millennial/Nexage UI that don't have ad units and you think tagging in Oath will be a challenge?

Any ad size can be set on the SDK and sent on a request. If the expectation is that the AdMob SDK would request an irregular ad size that can be filled by a standard size, wouldn't that be something we could handle in the adapter itself? i.e. map non-standard sizes to standard ones?

Yes, the adapter can handle converting a non-standard size to your supported sizes. I figured I'd check first though just in case your SDK already supported this. Which banner sizes does Oath support?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.