How to migrate from MGID to Adgora without losing publisher revenue

Define the migration scope around revenue protection, not full platform parity

The first mistake is trying to copy every MGID detail on day one. That sounds tidy, but it can drag a publisher into weeks of fiddling while revenue drifts. Start with one question: what must stay stable so the site keeps earning?

For most publishers, the answer is narrow. Keep the placements that pay, keep the traffic sources that convert, and keep the pages that already have history. If you are writing down how to migrate from MGID to Adgora without losing publisher revenue, the scope should be written in money terms, not product terms.

A good scope statement names three things: the exact section of the site, the revenue model behind it, and the time window you will protect. One site might only migrate 5 high-value article pages first. Another might need the homepage and 2 category pages. Tiny scope. Real protection.

Do not start with “full parity.” That phrase invites extra work. Instead, mark what is non-negotiable for revenue: the placement count, the ad density, and the page speed budget. If a change does not affect those three, it can wait.

A publisher once treats the switch as a redesign project and ends up touching 14 small settings at once. Then a decline shows up, and nobody knows whether the cause was a widget, a timeout, or a layout shift. Avoid that mess. Keep the first migration small enough to diagnose in a morning.

Audit which revenue-critical placements, widgets, and rules must stay unchanged

Make a list with 4 columns: placement name, current MGID behavior, revenue impact, and whether Adgora can match it directly. That list should include the exact widgets that sit above the fold, inside article bodies, and at the end of content, because those are usually the first places where RPM changes show up.

Focus on things that affect fill behavior, page load, and user experience. If a widget adds 1.5 seconds to load time, that matters. If a sticky element pushes content down and raises bounce rate, that matters too. A small delay can cost more than a fancy optimization ever earns back.

Look closely at delivery rules. Frequency caps, device targeting, geo filters, and content-category blocks can change the revenue mix fast. If any rule is undocumented, mark it clearly. Do not guess. Guessing is expensive.

Here is the useful habit: separate “must keep” from “nice to keep.” A placement that produces 40% of your page RPM belongs in the first pile. A decorative wrapper that only changes appearance belongs in the second. The same logic applies to widget refresh behavior, ad slot spacing, and lazy-loading rules.

• Placement names and positions
• Above-the-fold and in-content widgets
• Refresh intervals
• Device-specific rules
• Geo and traffic-source filters
• Page speed impact

There is one practical test. If removing a setting would change revenue more than it would change cosmetics, keep it in scope. Simple. No poetry required.

Build a baseline using the last stable MGID period

Before any cutover, take a snapshot of the last stable MGID period. Use 7 days or 14 days if the site has steady traffic; if traffic swings hard on weekends, include both weekday and weekend data. You need a baseline that reflects normal behavior, not a lucky spike.

Record the minimum comparison set: top pages, traffic sources, device split, viewability, and placement-level performance. If you skip device split, you may miss that mobile is carrying the entire account. If you skip traffic sources, a single referral partner could mask a drop elsewhere.

Put the numbers in one sheet. Then put them in another. That sounds fussy, but when the first 48 hours after migration get noisy, you will want a clean copy you can trust. Keep the baseline narrow enough to read in 5 minutes.

Include three revenue references at a minimum: page RPM, placement RPM, and total daily earnings. Then add one traffic-health measure, such as bounce rate or page depth, because an ad setup that increases clicks but drives users away is not a win. It is just a delayed loss.

One aside: do not compare the first migrated hour to a full stable day and panic. That is how people invent problems. Compare like with like, preferably the same hour of day and the same traffic source mix.

Recreate the current monetization flow in Adgora with the fewest moving parts

Your first Adgora setup should mirror the live revenue path, not improve it. Resist the urge to test 6 new ideas at once. The objective is continuity. A cleaner optimization can come later, after the account has proven it can hold revenue steady.

Start with the same placement order, the same content depth, and the same mobile-versus-desktop balance where possible. If MGID showed an ad after paragraph 3 and Adgora can do something functionally similar, match it first. Do not redesign the article body on day one.

If Adgora offers multiple formats, choose the one closest to the existing flow. You are not building a museum exhibit. You are preserving the revenue path. For a publisher comparing ad stacks, the Adgora setup should be boring in the best possible way.

This is where the internal reference can help. If your site also runs other monetization tests, the broader crypto advertising, monetization & Ad-Tech guides page is a useful place to check related setup notes without drifting away from the migration itself.

Keep the first configuration to the fewest moving parts: one account structure, one or two core placement types, and one reporting view. If a setting does not help you preserve revenue in week 1, leave it untouched. The best first launch is almost dull.

Run a controlled traffic split on the highest-risk pages only

Move a small, revenue-sensitive subset first. Pick pages that already earn well and pages that have enough traffic to show changes quickly. A 10% split can be enough to expose a problem without putting the whole site at risk.

Choose pages with different behavior. One long-form article, one fast-loading category page, and one page with mobile-heavy traffic often tell you more than a random sample of 20 URLs. If the split works there, you have evidence. If it fails there, you catch it before the damage spreads.

Use a simple split rule and keep it steady for the test window. Do not change the split every few hours. That makes the data useless. The goal is to compare revenue performance under similar conditions, not to prove that chaos exists.

Watch the highest-risk pages first because they are the pages that already carry the most revenue. If a page produces 30% of daily earnings, even a small decline matters fast. Slow pages, odd layouts, and ad-heavy article templates deserve special attention here.

One more thing: split by page, not by emotion. A page that “feels” safe may hide the biggest revenue drop. Numbers are less charming, but they pay better.

Watch for hidden revenue leaks during the first 48–72 hours

The first 48–72 hours are where hidden leaks appear. Ads may be live, the dashboard may look active, and yet revenue still drops because a slot renders late or not at all. Check for broken placement rendering, delayed loading, missing reporting, or traffic misrouting.

Pay close attention to mobile. A placement that behaves nicely on desktop can collapse on a smaller screen if the container width changes by just a few pixels. Also watch viewability. A live ad that appears below the fold too often will not hold the same earnings profile.

Look for reporting gaps. If Adgora logs impressions but MGID-era comparisons show a missing revenue bridge, the problem may be tracking rather than delivery. That distinction matters. One is a setup issue; the other is money leaving the site unnoticed.

There are three fast checks during this window: page load time, placement render rate, and earnings per 1,000 sessions. If any one of them moves sharply, stop and inspect the page before expanding further. Fast reactions save revenue.

A short sentence here is enough: wait. Then inspect. Then compare again.

Decide when to scale, pause, or roll back based on revenue thresholds

Decisions should not be made by mood. Set a threshold in advance. It can be a percentage band around your baseline, or a fixed revenue floor for the test pages, but it must exist before the first impression is served.

Use three actions only: scale, pause, or roll back. If the migrated pages stay within your acceptable range for the full test window, scale to the next set. If revenue slips but the cause is clear and fixable, pause and repair. If losses keep growing, roll back immediately.

Keep the threshold visible to everyone involved. That includes the publisher, the traffic manager, and the person checking reporting at 2 a.m. A threshold hidden in a chat thread is no threshold at all.

A simple rule works well: if the migrated group falls outside the accepted range for two consecutive checks, stop expansion. If the drop is limited to one device class or one traffic source, isolate it before changing the whole account. The point is to respond to revenue, not to noise.

There is no prize for stubbornness. If a page loses 12% and never recovers, scaling it only multiplies the mistake. Honest thresholds protect the account.

Lock in post-migration monitoring so revenue stays stable

Once the initial move is done, set a recurring review process. Weekly works for many publishers; daily is better for the first 10 days after cutover. The point is to catch small changes before they turn into a quiet revenue slide.

Review three things every time: placement performance, traffic mix changes, and reporting consistency. If mobile traffic rises by 15% in a week, the account may need a different placement balance. If a referral source appears suddenly, that may change user behavior enough to matter.

Keep a note of any layout edits, content format changes, or campaign shifts that happen after the migration. Without that record, you may blame Adgora for a dip caused by a site redesign or a bad traffic source. That mistake is common, and expensive.

This is also a good moment to compare your setup with other ad tech topics when needed. If you are adjusting monetization strategy beyond the migration itself, the ad tech glossary can help keep terms straight, and the broader crypto ad network for publishers article is useful if your revenue mix includes crypto-related traffic or offers.

Do one more thing. Archive the baseline, the threshold, and the final accepted setup in a shared doc. Future changes will be easier, and the next migration will not start from zero. That saves hours.

Small problems compound. A placement drift of 3% this week can become a 10% swing next month if nobody checks the numbers. Keep the review rhythm alive, and the revenue stays where you need it.