Ok guys - I was just wondering what some of you do with regards to keeping your IPs healthy and delivering month after month. Obviously we're not talking about GI per se but to any other domain that requires a certain level of IP reputation. If you're able to keep IPs mailing on GI then I'm all for hearing how you do it but while I was chatting with other guys about how I keep a range inboxing I thought it would be a great topic for conversation here. So; what do YOU do? Let IPs rest? Drop to a different data set? Work in your o/c data sets frequently? Drop to a high opener/clicker offer? Drop a joke? I'd like to hear what you guys find helps keep IPs makin' the green month after month!!
I had experience when I lets my IP rest for over a month then go back and pick them up, they are still inboxing, and I'm mailing GI. The trick is you gotta keep track of which IP is still working and which one is not. Like I have to do resource inventory and make a calculation which IP is actually bringing in money for me and which one I shouldn't bother any longer.
DA has something like this built into the MTA if memory serves. I have asked ROBO if they could also put something like this into their own MTA as it would make life much easier. I guess they have kicked the idea around for a spell, and are now looking into licensing or whatever is all involved in doing something like this. Obviously it would make life much easier if you could automate some of this busy work. In regards to the O.P...... rotate data sets and offers. Drop the volume, and switch to "clicky", often times low converting, but low complaint offers that seem to get a lot of views but just do not convert for whatever reason. However, they also traditionally do not get complaints whether because of the brand name or whatever.
Although I've never done this, I guess the particularly spreadsheet-happy person could simply set up their links so the subid = sending ip (assuming 1 ip per send of course). You'd also need to get the date in there, otherwise one particular good "pop" in the numbers could skew your results and make you think the IP is still strong even though it's not. But anybody doing this has too much time on their hands I'd think.
I don't see the purpose to this honestly. Delivery % by IP is a stronger metric. Revenue by IP is very misleading. Unless you're doing exact list, exact offer, exact time of day, etc. even then, too many variables. Then if you see a bump in a revenue on a few ips, you'll tend to hit those IPs again, and guess what? Those IPs continue to have climbing revenues over the others you hit less, which is why it's sort of useless to track. At least with delivery percentage by IP you get a better idea of health...
Would really like to hear from "mailers" on this topic, not a platform owner with promotion in mind.....and I thought the jist of this thread was IP health and longevity? not revenue and delivery analysis? Just sayin
ok BeB - take a day off of throwing shots at SG. I watch my logs day in and day out and it's my contention that you cannot simply sit back and let an automated system of any design mail away without diminishing your IP rep. And simply injecting new data periodically isn't the answer either but it is a great way to build up a solid deliverables file that can be used to break in new IPs. Now I'm speaking directly from my own experience when I say that I watch my IPs (I mail AOL) benefit from a regular "refreshing " that I get from hitting a completely different domain. As an example when I see the 421 service unavailable (soft bounce) code getting thrown at me at a % that I deem too high I kill the drop, queue up a data set for say Yahoo and let it run out. Once this set is finished I can then requeue the AOL data set and immediately see decreased soft bounce/deferrals as well as an increased open rate. If I didn't see it help, I wouldn't do it. But it does. Now while some will say "just power through 421's" and others say "just set it and forget it" I'm of the belief that putting a little extra time and attention into your IP health directly affects your IPs longevity and therein lies a strategy to keep your ranges performing at their best which in turn will be reflected by the things SG brought up such as revenue. And who doesn't like more revenue!!??
I agree with SuperG spot, simple method, learn how to backoff properly. My IPs are fine and stay that way. Unless I buy a list from someone on mailerforum and then mail it without the condom. That always translates to aids.. but you know how that works and data is a whole diff part of the equation.. Purely in an IP sense.. just simply listen to what the ISPs are telling you and "backoff"
True. A lot of people that aren't coders forget that automation isn't just writing a line and flipping a switch. It can take weeks or months to properly "train" an algorithm to handle situations properly. Especially when it's done correctly. Example: Rate stepping as the process of having the sending speed change at a variable time isn't hard to code. But having it step the right number at the right time is what makes or breaks it. It's not about doing it - it's about knowing when and how to do it. But then again, I do prefer automation in general. As to the general thread topic: I've always been a fan of backing off longer than "the norm" since I see success & IP quality on an actual IP level, not a "range" level. I don't look at it like "back off <X> hours/minutes/whatever when seeing <code Y>" as a static value no matter what the rate of the IP is - but then again I don't just back off. I also drop the rate by a variable amount based on how I've trained the algorithm. Ex: Mailing AOL and seeing a T1 may result in a <X> hour backoff. For mine, I most likely won't just backoff for <X> hours. I'll backoff for <X> hours modified by the rate and sending history (with min & max values, obviously), and then also modify not only what emails are in the queue but also the sending rate in general. Think of it like a probation period. There's no reason to halt sending to a TLD because 4 IP's out of 500 are having isolated issues, but you just happen to see all 4 of those at the top of your log and think "OH SHIT!". TL;DR -> I always try to look at rep on a per-IP level instead of a per-range level and write rules specific to that. Usually ends up ahead that way, at least for me. Talking about the majors.
This is going beyond "simple" automation which is where most platforms are at; and while it's true I'm not a programmer I do understand what's going on behind the scenes for the most part. What you're talking about here is adaptive delivery, much along the lines of what DA does. And if memory serves me, you designed your own platform and as such it's obvious you have your hands on all the moving parts which is a luxury not many of us have. Even SG being the designer sees things from a different point of view as I (or any other mailer might) do. As I'm a "hands on" kind of mailer without the skills to build my own shit, I have to watch my logs and modify on the fly. Don't get me wrong; I like it but there's no question that if it were more automated according to how I do things now I'd spend a little less time at the ol' PC than I do now. My post was intended to elicit response from others that are mailing day in day out and learning as they go more so than it was for the programmers/platform designers as from what we've seen above you clearly take a different approach to your IP health and longevity. While I kept it general and fairly bland; believe me when I tell you when I talk to the guys that built the platform I use now my conversations are more along the lines of your thoughts as I'm trying to improve upon what they built because again; I'm mailing on it while they built it and we look at things differently. I do appreciate yours and SG's replies however.
Oh, completely. I wasn't detailing that for the sake of debating what's better - it was more-so to make the point of trying to look at things on a deeper level than most do. With you looking at the logs yourself you actually get the ability to interpret each response and the issues first hand. Programming, if not coded for it, can easily miss certain things that they're not specifically trained for. Getting back to the main topic, though. The aspect of the per-IP level can still be done manually depending on the information your platform gives you, maybe just not on a specific IP level but grouped. In other words, send at a 15 rate for <X> timeperiod (talking TLD). Any IP that was put into backoff you can put into one group, and any IP's that didn't you can put into another. On the next block of time send the "better" ones at a slightly increased rate, and see where they end up. That's more along the lines of what I was saying overall: don't let your army be held back due to a few bad soldiers, if you catch my drift.
Bingo.. "With you looking at the logs yourself you actually get the ability to interpret each response and the issues first hand. Programming, if not coded for it, can easily miss certain things that they're not specifically trained for." -Bofu2U. Watch the logs and see whats happening and adjust accordingly.. I find it's best to focus on one ISP at a time, dial it in.. and then on to the next. Also best to set your backoff policies per ISP and not in a global all in one configuration kind of sense. I only mention this because so many use PMTA incorrectly with that one mistake, I personally have not tried the other major MTAs like ironport so I wouldn't know how they manage backoffs. I am still 1 year away from having the ultimate satisfaction of an internal MTA (Programmer busy with the Database and traffic features I want).
Also another unfortunate side effect of dealing with cos that are too mailer friendly.. You can be doing everything right and your neighbors can reduce your ability to send mail out if too much heat is in the kitchen. KEEP IN MIND: One Size never fits all, you are best training your policies per range to "keep" them. I.e. a hosting company that has 0 tolerance for "spam" and will only give you a /25 or less will do amazing things in terms of inboxing.. at the same time you have to walk on eggshells and only use data that is proven, you have already mailed it for a long time without problems type of data. Just like in the real world, real estate is also important. Similarly you can get "virgin" ranges from someone selling way too heavy to mailers and get cloudmark or hop based blocks right off the bat. Yes the IPs are clean, but the route isn't .
