Use case is I only need to check the segment query (like “customer_tags CONTAINS ‘vip’ “) for my app, I do not need to retrieve customer ID / names / email address etc, I just want to access the segment query.
The “read_customers” permission will spook merchants that an app will be able to access their customers name / email, reducing installation rate.
Hi @soulchild,
I’m happy to help submit some feedback on your behalf, but to do so, can you share a bit more about what data you’re trying to access and what query you’re making exactly.
If you’re only retrieving the Segment object specifically, I could see a case being made for removing the read_customers scope requirement since the Segment object doesn’t actually contain any customer data in the object, but we’d need to discuss this with our developers further to confirm.
Hi Kellan, the data I am trying to access is the “query” attribute from the segment of an automatic discount. The goal is to check what query is used for the segment, to see which tags or conditions are used for the automatic discount eligibility.
Example query:
query {
automaticDiscountNode(id: “gid://shopify/DiscountAutomaticNode/1234567890”) {
automaticDiscount {
... on DiscountAutomaticBasic {
status
title
context {
... on DiscountCustomerSegments {
segments {
id
query
}
}
}
}
}
}
}
Yes, I would appreciate if you can specify the feedback to remove the need for the “read_customers” permissions to get the segment data, as no customer data are actually retrieved. Thank you
Hi @soulchild,
Thanks for providing that context on the query you’re running. I can confirm I’m seeing the same behaviour on my test store, even though the DiscountCustomerSegments object only requires read_discounts and only returns segment objects, the segment object itself does require read_customers
Personally, I agree that this doesn’t seem necessary as it’s not returning any actual customer data, and I’m currently discussing this with our developers further to determine if this is expected behaviour that segment requires read_customers or not, and if it is expected behaviour I’ll be submitting feedback on your behalf as previously mentioned, and if it’s not expected behaviour, we’ll look into correcting that further.
I’m also keen to see this scope requirement removed in this scenario, or at least reduced. To provide a Segment picker within my app to support the new Discounts contexts, I’m required to request the read_customers scope, which feels excessive given the actual use case.
The app only needs to read segment IDs and names, not access customer data. Requesting a sensitive permission like read_customers just to enumerate segments is likely to alarm merchants unnecessarily and create friction during install, despite there being no actual need for customer-level information.
Hi @soulchild and @ethan_l,
I’ve been discussing this behaviour further with our developers, and at this time we can confirm that this was expected behaviour when this API object was added, as it is a bit of a grey area since the DiscountCustomerSegment.segment field does return the segment filter which could potentially contain protected customer data that the merchant used to create the segment.
They did mention this was a grey area and are open to reviewing this further, and we have submitted official feedback on your behalf regarding this. While we can’t guarantee when or if this will be changed, I can assure you that our developers and product managers do take all of our merchant and partner feedback with great value when determining future features and platform changes, and I would recommend keeping an eye on the Shopify.dev Changelog to see if this does get changed in the future.
Hi Kellan,
Can you elaborate more on the filter part? I don’t see the filter field in the documentation.
I apologize, I should have been more clear about that. I was specifically referring to the customer segment query which is returned, that can contain filters within the query that has protected customer data.
For example you can make customer segments that returns customers based on email, country, region, distance to a location, etc.
