Last active
August 29, 2015 14:07
-
-
Save iurevych/85f1f443efd6df2a2316 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
#1 I'm sure I'm biased from my position | |
#2 I really want to get a core toolbox of flexible features we offer | |
and then shut the doors to a customer by customer basis of customization | |
#3 PC - FTW | |
#4 LOL~~~ had me cracking up! | |
====== | |
#1 It feels like this might be because they themselves are crunching to get the site out | |
the door with minimal hiccups. | |
#2 "Good looking out" — in what context(s) can I say that? | |
#3 I will be going step by step via email in getting them integrated. | |
Doing an every page integration to service only the basic program now (PP + SA +DASH) | |
with product/every page sharing to come later in the year/next year. | |
#4 Their dev cycles are few and precious | |
#5 Beyond that we’ll need a separate action plan for getting their other campaigns up | |
to a functioning point. | |
====== | |
#1 We are pencils down on the 17th. Context: We need the campaigns finished by the 10th | |
so that we can test them with the client. We are pencils down on the 17th. | |
#2 We decided to increase our "defense" even more: | |
We will always handle double-integration cases in our per-client integrations. No more nightly fuck-ups even if the client fucked up | |
We will push email notification if the client uses more than 1 js lib on the page | |
We decided it is better to revert SFLY integration back to where we were registering purchases on a page-load without any custom functionality like "show/hide". | |
Better not to use POST in our per-client integrations to avoid dealing with IE | |
We need to implement an ability to send custom data from JS integration to our reports so we can segment traffic based on the data we pass. Then we can tell Cara an exact # of times we didn't show campaign visually without scraping server logs. | |
Please tell us what report we need to extend for #5 | |
Right now we can only give them visual control. As you see, giving them functional control will ruin the relationship with them as a client. | |
Are you okay with incorrect Impression metrics in our reports? I mean, no matter what method they trigger (hide/show), we will increment impressions anyway since we are generating an iframe, just without showing it to a user's eye. | |
#3 Mike, we can't be 100% sure T&T didn't do anything weird. Tasha, Pavel: let's make sure our demo integrations with hide/show work across all supported browsers. Then let's make around 10 test purchases to see how they initiate hide/show — we can put console.logs even to see them calling us. | |
I'm including devs just in case someone would be interested in getting anything else valuable for us. | |
Oh, and I also like Mike's idea: let's extract the code from _showVisibleCurebit into a new temporary method and execute it 100% of the time on page-load. This way we can be sure that our functionality works. | |
We will review SFLY integration on Monday, our morning. It is better to discuss it collectively since the information is scattered. We need to retrospect, fix, and make sure it works as desired. | |
#4 We did GTM integration for Linio or Dafiti, nothing special here besides the fact that GTM doesn't like document.write() — we can easily avoid it by using a Container option. | |
To set up their per-client integration with GTM, they need to place our current integration instructions (_curebit_purchase for PP, _curebit_affiliate for SA) in their GTM and give us the code snippet that we can include on our test page to play around with it for a while and make sure everything works. | |
We will have issues with PP integration then since we are relying on document.write there which means place iframe where the Lib script tag is. And if our lib will be placed inside HEAD, it will never be visible obviously (because by standards, only BODY is visible to the human eye). | |
We will need to tweak their PP to use the container, which is a pretty quick task, and then we are good to go. How to approach this: we need a confirmation from you on doing that, then we will also need to make a few (~3—15) test purchases on ZOZI to make sure everything works as desired. | |
If ZOZI will ever decide to move _curebit_purchase and _curebit_affiliate declarations into HEAD — no prob, nothing is required from our side. | |
As you see, only moving the cat into the box requires our attention. | |
#5 Hey guys. I see you recently needed to block email from going out to a user if the campaign is inactive. | |
As you already know, if the campaign is deactivated, the Advocate won't receive his reward email. But there is one case where he will receive an email — reminders. If campaigns shut down today, but we already put reminders into a queue for tomorrow, they will go out. This uber-simple condition inside the email sending criteria always checks for the campaign status before going out http://monosnap.com/image/6BlKADenagANIOqlVtBRD3h5xAXBHe.png | |
Note: personally for us, there is nothing wrong with sending the reminder if an Advocate didn't use his reward. But assuming there will be such a requirement, you can use this condition. Again, it is only relevant for reminders that are in a queue already. The default behavior to send them out is reasonable, and there is no need to change it. This condition is to block sending email only when needed by request. | |
Let me know if you need anything else. I would double check my words are right. This condition was checked with developer. | |
#6 I would propose to be more consistent design-wise for the navbar: instead of social icons I would put an orange CTA "INVITE FRIENDS" or "SHARE NOW" and once user shares all available methods we convert it into another CTA. | |
I think that CTA should look like a button. Icon makes less clicks from the theory. Not sure why they want to reduce clicks. Instead of being intuits we can be fact-based by running a split-test "button 'INVITE FRIENDS'" VS "icons". | |
No need to limit the functionality if its a bit harder for us. If that's a requirement, we will implemented. I was mostly concerned about the design. Design elements should always have straight meaning: in our case social icons may mean links to social profiles for some % of users. No need to take my words seriously, its just my worry. | |
Split tests make us get a valuable information we may take from every design we run which increases our design confidence. Its totally fine if we don't have enough resources or/and mind power to take care about them at the moment. | |
#7 Nope, the problem is different from what Mr. Pimp describes. The logics is following: | |
I'm a guy, sharing with girl | |
Right after share I get a coupon code out from AYR coupon list triggered by email sharing incentive | |
Advocate Reward Confirmation email is triggered from AYR | |
Friend Share email is triggered from AYR as well | |
The most complicated part here is rewarding Advocate since as you already mentioned Advocate is created inside Friend's domain. Based on Advocate gender we will code up a different appearance + copy as 2 states inside email template, so Advocate Reward Confirmation templates are identical across Bonobos and AYR sites. In addition to template we set up sending condition that turns true if gender == "male" on Bonobos side, and gender == "female" on AYR. | |
Now the most complicated part goes. Since coupon codes are different across sites for Advocate reward we need to setup 2 email sharing incentives for each campaign on both sites with following conditions: | |
Trigger Bonobos coupon code if gender == "male", else: return false | |
Trigger AYR coupon code if gender == "female", else: return false | |
If we may use same coupon list across both sites we won't have to implement multi email sharing incentives. | |
As you see recent requirements with rewarding for email sharing with different coupons made all complication which we didn't have when discussed earlier before. | |
Disregard the part with email sending criteria based on gender, we aren't going to use this part, things are easier here, that was our initial idea but we decided to just code up different appearance based on gender, not sending criteria. | |
#8 Dear sales, let's be more mathematic about potential of each copy of the banner. If you think some variation will 100% win, in real life at can lose. We should always Measure (as Lean methodology says) how well _each_ of the variations perform since its going to be shown to a broad range of users. | |
For example, "Learn more" in my opinion will lose since I as potential user who clicks on the banner may expect some explanations on the page I visit, but in fact I only see a boring Apply form — my expectation are broken and as a result I leave site. But "Contact Us" will make correct expectations. | |
If you see some grammatical errors let's fix them for sure, but our point is to measure a lot of variations to find out what wins. Do you agree on experimenting? | |
#9 Hey, we proposed to run a split test for Tinyprints share email but our idea got rejected, and we feel it was rejected only to save time on approvals with client. | |
Proposition here is that we should take lessons from everything we implement/run. To do that we need to run experiments on some percentage of users (let's say 10%) without asking client about it. Clients have their own vision, but usually we have a better ideas on improving conversion rates. | |
Do you think we can run experiments on 10% of users without asking for approval? These would not be dramatic changes, here is the proposed test for Tinyprints share email: one | two. | |
What do you think? | |
#10 Treat it as a thing that removes Signup view from SA campaign. We usually need to un-check it for campaigns where we have signup + share pages in one view (aka Hotels, most recent Daifiti and new bonobos+ayr). | |
Technically, if you un-check the checkbox Advocate can share anonymously without entering his email (we mark such affiliate members with "—" instead of actual email). In this case there is no sense in Signup page if we allow sharing without signups, so that's a perfect fit for mixed (signup + share) and instant reward campaigns without email as a sharing channel. | |
For mixed campaigns we always validate signup email field and make it required so we can associate affiliates with their emails. | |
Hope that makes sense. | |
=========== | |
Alternatives: | |
1. Are you working at the moment? | |
a) What's up? | |
b) Can I have your attention for a moment? | |
c) Are you busy? | |
d) Hey, can I ask you something? | |
2. If yes, doing what? What exactly does your job involve? | |
a) What are you working on right now? | |
b) What are you on right now? | |
c) What are you busy with right now? | |
3. Have you always done this kind of thing? | |
a) Are you keen doing this kind of thing? | |
b) Have you used to do this kind of thing usually? | |
c) Are you proficient doing this kind of thing? | |
d) Are you doing this kind of thing like a pro|(boss?) | |
4. How do you get on with the people you work with? | |
a) How do you become friends with your colleagues? | |
b) How do you relate with your colleagues? | |
5. If you're not working, have you got any idea what you'd like to do in the future? | |
a) If you're idle, do you have anything in your mind to work on in the near future? | |
b) If your task-list is empty, do you know what to do next? | |
c) In case you're free, do you know what to jump on next? | |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment