I create HITs to ask turkers to go to my website to perform tasks, after which I will create a separate HIT for them to verify their information and get paid. I can get the HIT Id of the payment HIT, how can I direct the turker to a webpage to get paid, without knowing the worker Id etc.?
I only know you can direct turkers to a page with group Id, like this:
https://www.mturk.com/mturk/preview?groupId=XXXX
Can I do similar thing with HIT Id?
You can't specify a hit id in the URL but you can ensure that your HITs will be assigned a different Group id if they have a different title , pay or other attribute. You can then use the group id which will be unique pet HIT.
To make things simpler for you and the workers just add the secret code or verification to your original HIT.
Related
When an order is created at Shopify, a callback is initiated from Shopify that hits the webhook given in the settings.
The parameters that it uses to hit the webhook, those contain multiple emails, and there are no docs for those.
You can see those parameters here: https://codebeautify.org/jsonviewer/cb3e0c52
One email is in the root. 2nd is by the name contact_email, and the third one falls under customer and goes by the name: email.
As of now, there is no documentation that states which email stands for what.
My question is: how would I know which email has the customer used for purchasing the product, and it would be the very email that I will use for contacting back with a customer.
Shopify webhooks: https://help.shopify.com/en/api/reference/events/webhook
You can do the following. One. Check to make sure a customer record was attached to the order. Surprisingly, it has been known to happen that you get an order without a customer due to a glitch. Assuming you have a customer record, use the email field from that. If the customer record does not exist, the one at the root is likely your best bet.
That is it. Any other emails floating around can be safely ignored by you. And also, be double dog sure you do not email this customer unless you are allowed to. Otherwise, you are spamming, and that will get you hammer-banned by the merchant, who will take the brunt of the abuse from your spam.
That means checking the buyer_accepts_marketing attribute.
I have just published an app, and so far my purchase rate is below 1 per month, so dealing with refund requests, and refunding the correct purchase would be easy.
I am concerned when the rate increases, I may have no way of telling from a "contact the developer" email, which user request is associated with an order-id, and thus be able to refund the correct account.
The android Google Play does not seem to give an order-id so the user can help associate themselves, and the console does not seem to allow association with an email address.
I received this reply from google...
Sign in to your Play Console.
On the left menu, select Order management. Search full order with order id or email address of user.
Check the boxes next to the orders you'd like to refund. To refund multiple orders at the same time, make sure you select orders placed
by the same user.
Select the appropriate refund reason.
Select Submit.
So given I knew the email address of one of the customers, I was able to search for exactly that customer, and it highlighted the transactions made by that user.
It didn't seem to cope with wildcards, or partial matches (makes sense given privacy).
I have a requirement to do 3rd party age verification before I ship an order. I'm using a company called EVS for this. They released a shopify app recently, but seems partly baked. It requires a user to enter date of birth when registering for an account and then triggers the verification when the user places an order. The main problem with that is that it's rare for a customer to actually create an account before ordering for the first time -- instead they order first, then shopify emails them to create an account after the fact. Creating the account afterward does not allow the customer to enter DOB.
So I'm planning to implement my own solution. I can use EVS's API to run the verification by sending a combination of Name, Address, DOB, DL# and State, and last 4 of SSN. I have already built a proprietary order management system that pulls in customer and order data, and I can write a client to perform the verification.
I'm less savvy on the shopify side. I need to balance customer friction when placing an order for the first time, against having to do a lot of manual work for verification.
Below are the options I have conceived. Are there any other options? Any ideas for a better solution? Keep in mind I need to verify a customer once. I can tag the customer account as verified, and once verified it's business as usual.
Alter shopify templates to only show the checkout button when a user is logged in. If not logged in, show a "Create an account" button instead. That way the user provides DOB during account creation and the EVS app works as designed.
Set up a separate verification site like verify.my-domain.com. I can trigger an email to the customer upon order creation and ask them to verify. (May have issues with incorrect email addresses or spam filtering.)
If customer is not logged in, or account is not age verified, and they click Checkout, I can redirect them to a page. I can use a form on the page to do the verification. If verification passes, send them on to checkout.
For option 3, I don't know what shopify allows or what best practices allow. Can I use js to pass data to my own server on a different subdomain? Or post the form to another subdomain and then redirect back to shopify?
I'd appreciate any thoughts or suggestions.
You have pretty much summed up all your options, to clarify on them a little:
You can require that customers create an account in the store checkout settings. /admin/settings/checkout
This would work, you could iframe it in too on a custom Page. Or, better, use cross-domain calls or jsonp.
This is a little convoluted and you would have to persist and maintain lot of external state. I'd avoid this
I think a combination of 1 and 2. Turn on "require customer account". Modify the customer account creation page. Implement a cross domain policy with your server which will host custom code leveraging the EVS API.
I'm not sure if you are selling tangible goods or not but with stringent policies on users' age you have to bear in mind that shipping addresses could change. For a tight integration you should look at having webhooks whenever a customer is changed and make sure all their data is still valid since their last EVS approval.
I've been looking into this quite extensively and we've spent a number of hours experimenting with options. Our client in this case is on Shopify Plus so we do have the benefit of access to checkout.liquid.
Our research has led us to believe that one cannot pass the required 'customer note' of the date of birth to the checkout should they be attempting to checkout as a 'guest'. Perhaps because the 'customer' does not yet exist.
Our options have been narrowed down to:
Write a custom backend app that allows Shopify and EVS to communicate directly (XML API on the EVS side) in the checkout process or just prior and then pass the verification status back to Shopify to allow the order to proceed, or append some relevant status marker for the fulfillment department to act accordingly. The EVS app doesn't prevent the order from proceeding, but does flag the customer's age as unverified in the Risk Level panel in the admin. This would be quite a substantial project and by no means low hanging fruit. There is also risk of re-doing a lot of what the EVS app does already and running into they same obstacles they did.
Force customers to register prior to checkout (if not signed in). This seems the most viable approach. The only caveat being that existing customers will not have the customer note (birth date) and we'd need to build a smaller backend app to allow them to append this to their customer account via the Shopify API (this cannot be done via liquid).
These are our findings and I'd love to know more about how you ended up approaching this.
How can I have access to bigcommerce's %%GLOBAL_CustomerId%% variable?
I create a sample template and logged in with as a user. That variable doesn't show up. Isn't it suppose to be a Global variable?
Background: I want to create an app for bigcommerce that can identify a user base on their customerID. If I can't grab that variable, you guys see any other way to work around this?
It's not immediately clear in the docs, but you can use %%GLOBAL_CurrentCustomerEmail%% anywhere on the template to get the email address of the currently logged in user.
If you need the customer's ID, then you can query the API with the email as a parameter.
Personally, I'd rather "trust" the customer's email as a point of identification, because you never know if the Bigcommerce ID's may get changed or not (example: Customers are deleted and then reimported, now having brand new ID's).
On a subject of security though, you cannot trust client side data, and should attempt to mitigate fraudulent requests through the use of a CSRF token or some similar measure. Otherwise, anyone can send you an email address and receive back a list of that person's favorite products -- golden information for say, a targeted advertising company, or just your suspicious next-door neighbor Joe who seems to always be conveniently checking his mail right when you get home from work, but never says anything when you walk by, not even a wave or a smile, despite the fact that you all have been neighbors for quite some time now. Like, should I say something? Hahaha, I kid I kid.
I'm using a google events tracker like this:
_gaq.push(['_setAccount', 'UA-1422398-23']);
_gaq.push(['_trackEvent', 'BookingRequest', 'Parent Name', $('#parent_fname').val()+' '.$('#parent_lname').val()]);
In this case, let's say I can track how many requests were submitted.. is there a way to track these specific users, and see the traffic source, and if it's Google, then what keywords they searched my website by?
Basically I want to see the people booking online, and see how and where they got me... and hoping there's a better and more elegant way than to have a field that asks "What did you type into Google to find us?"
Putting fname and lname into GA is a violation of Google Analytics terms of service. See number 7 PRIVACY.
Custom vars can be used to determine user type and/or login status. See Session-level Custom Variables
For example, if your website offers users the ability to login, you can use a custom variable scoped to the session level for user login status. In that way, you can segment visits by those from logged in members versus anonymous visitors.
But, don't try to put the username in GA either:
While the username or user ID is not directly PII, if it is used to tie to a person from a backend system…that’s a violation of the Terms of Service.
To see the traffic source of the events, go to Content, Events, select the event you want, and add the secondary dimension of Traffic Source (just above event title in report).
Here is a Custom Report for Event Labels that drills down by source then keyword. Just log into GA and go to the URL.